1) Language fragmentation. Java developers aren't going to use a C# library or a PHP library. So instead we're stuck with, "If you're on Python, use X; if you're on Ruby, use Y..."
2) Password storage is a problem that's easy to get wrong without knowing it. If you have a DIY password storage system that accepts valid passwords, rejects invalid passwords, and looks scrambled when you view them in the database, it's hard for non-experts to notice that it's broken in any other way.
3) The combination of those two problems results makes it difficult for the security community to reach consensus on good language-specific libraries. Competent Java security experts can't easily evaluate a PHP scrypt library.
So all they can say is, "allow long passwords, use per-password salts, and use PBKDF2/scrypt/bcrypt with a pretty big work factor, but don't do it yourself."
With HaXe though you might be able to swing something like this. In fact something like passlib (python) would be beautiful but dangerous - imagine cross language bugs ( ie the same bug in Java, C++, Python, etc.)
I wonder if in large organisations it'd be better to have a single service handling password management (with split databases still). That way you could lock it down to one set of IPs, all access monitored and more importantly one password storage implementation.
Such a thing exists, it's called LDAP. Bonus effect, many LDAP implementations (Windows AD, OpenLDAP, Lotus) give you replication and failover for free.
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Why not?
1) Language fragmentation. Java developers aren't going to use a C# library or a PHP library. So instead we're stuck with, "If you're on Python, use X; if you're on Ruby, use Y..."
2) Password storage is a problem that's easy to get wrong without knowing it. If you have a DIY password storage system that accepts valid passwords, rejects invalid passwords, and looks scrambled when you view them in the database, it's hard for non-experts to notice that it's broken in any other way.
3) The combination of those two problems results makes it difficult for the security community to reach consensus on good language-specific libraries. Competent Java security experts can't easily evaluate a PHP scrypt library.
So all they can say is, "allow long passwords, use per-password salts, and use PBKDF2/scrypt/bcrypt with a pretty big work factor, but don't do it yourself."