If the password hashing APIs asks developers to generate a salt on their own it's neither easy nor safe. I've worked on password hashing recently, and I think

If the password hashing APIs asks developers to generate a salt on their own it's neither easy nor safe. I've worked on password hashing recently, and I think the best interfaces should take only a password, and return a hash. Modern password hashing algorithms, e.g., bcrypt, scrypt, etc., usually also need a set of local parameters. The API should hide them as well, and expose only a set of interfaces with safe and sound preconfigured parameters, which in turn determine how much CPU time and memory space will be used. One disadvantage of this approach is that it exposes the local parameters, hence make it a little bit easier for attackers. This is exactly how crypto primitives have been designed. If the designers of AES ever let people choose the key size, sooner or later some people would shoot themselves in the foot, and set the key size to 1-bit. If you think this is an extreme example, it actually has happened, not in some obscure API that nobody uses, but in the very XMLDsig standard published by W3C [1]. Regarding password hashing standards, I found many misuses of libscrypt that would make it extremely easy to recover passwords. But I'll save the details for another blog post or something. [1] http://www.w3.org/QA/2009/07/hmac_truncation_in_xml_signatu.html http://www.w3.org/QA/2009/07/hmac_truncation_in_xml_signatu....