While NIST SP 800-132 is not specifically about password hashing, and especially not about passwords for authentication there is a strong recommendation to use PBKDF2 especially because of its brute-force resistence.

The upcoming NIST SP 800-63B draft (Digital Identity Guidelines Authentication and Lifecycle Management) however mentiones PBKDF2 explicit, but it also askes for a HMAC based pepper:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP 800-­132]. The salt value SHALL be a 32­bit or longer random value generated by an approved random bit generator and stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC [FIPS198­1]), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

There is a lot to argue about this, but in any case it asks for "approved hash function" which rules out scrypt and bcrypt. And I love the fact it calls out for separate storage of a pepper. This is why I revived my attempt to define a common PBKDF2 format: https://github.com/ecki/habibi-passwordhash

While NIST SP 800-132 is not specifically about password hashing, and especially not about passwords for authentication there is a strong recommendation to use PBKDF2 especially because of its brute-force resistence.

The upcoming NIST SP 800-63B draft (Digital Identity Guidelines Authentication and Lifecycle Management) however mentiones PBKDF2 explicit, but it also askes for a HMAC based pepper:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP 800-­132]. The salt value SHALL be a 32­bit or longer random value generated by an approved random bit generator and stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC [FIPS198­1]), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

There is a lot to argue about this, but in any case it asks for "approved hash function" which rules out scrypt (partially as it intentionally uses a PBKDF2 step) and bcrypt. And I love the fact it calls out for separate storage of a pepper. This is why I revived my attempt to define a common PBKDF2 format: https://github.com/ecki/habibi-passwordhash

While NIST SP 800-132 is not specifically about password hashing, and especially not about passwords for authentication there is a strong recommendation to use PBKDF2 especially because of its brute-force resistence.

The upcoming NIST SP 800-63B draft (Digital Identity Guidelines Authentication and Lifecycle Management) however mentiones PBKDF2 explicit, but it also askes for a HMAC based pepper:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP 800­132]. The salt value SHALL be a 32­bit or longer random value generated by an approved random bit generator and stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC [FIPS198­1]), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

There is a lot to argue about this, but in any case it asks for "approved hash function" which rules out scrypt and bcrypt. This is why I revived my attempt to define a common PBKDF2 format: https://github.com/ecki/habibi-passwordhash

While NIST SP 800-132 is not specifically about password hashing, and especially not about passwords for authentication there is a strong recommendation to use PBKDF2 especially because of its brute-force resistence.

The upcoming NIST SP 800-63B draft (Digital Identity Guidelines Authentication and Lifecycle Management) however mentiones PBKDF2 explicit, but it also askes for a HMAC based pepper:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP 800-­132]. The salt value SHALL be a 32­bit or longer random value generated by an approved random bit generator and stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC [FIPS198­1]), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

There is a lot to argue about this, but in any case it asks for "approved hash function" which rules out scrypt and bcrypt. And I love the fact it calls out for separate storage of a pepper. This is why I revived my attempt to define a common PBKDF2 format: https://github.com/ecki/habibi-passwordhash