Due to regulation, my company needs to be FIPS-compliant.

I was looking at the current list of FIPS-approved cryptographical methods and I notice that neither bcrypt or PBKDF2 are in this list.

  • Does that mean I should use salted SHA-512 for password storage?

  • Is that a good idea?


FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password hashing.

The closest you can get in the NIST world is SP 800-132, that lists approved methods for password-based key derivation, something which is quite close (but not identical) to password hashing. NIST approves PBKDF2, as long as the underlying primitive used in PBKDF2 is itself "approved" (i.e. it is HMAC used with one of the SHA-2 functions).

| improve this answer | |
  • 5
    NIST does not say, but my guess is that NIST considers the whole premise of password hashing (storage of password verification tokens, "hardened" against leakage of the storage system) to be a doomed model, to be shunned altogether. A more NIST-compatible model of an authentication server would be one where what is stored for password p is HMAC(K, p) for a secret key K which is kept in tamper-resistant hardware (i.e. a HSM, preferably a FIPS 140-2 compliant HSM). – Tom Leek Aug 31 '15 at 17:45
  • 1
    @JohnAssymptoth - Unsalted SHA-512 is little better than clear-text. You can read about password storage from the other bear here – Neil Smithline Aug 31 '15 at 20:21
  • 6
    @JohnAssymptoth: using SHA-512 "alone", or with some custom "salting", is not acceptable. If you really need to use SHA-512 then at least use it with PBKDF2. PBKDF2 internally uses a "PRF" (PseudoRandom Function family), and in practice always uses HMAC as PRF, and HMAC itself uses a hash function, and that function can be SHA-512. Some implementations of PBKDF2 systematically use HMAC/SHA-1, but some others will let you use SHA-512. – Tom Leek Aug 31 '15 at 20:32
  • 1
    @kasperd While hashing (and salting) is surely better than storing the data in plaintext, it is not that much better for the average user. When attacking a single user (and known salt + hash), the cost of brute-forcing the password is about the same as using a non-salted hash (or about doubled if salt + password are together longer than one block of the hash function, while the password alone fits in just one block). Introduction of a salt just helps against untargeted attacks (i.e. those attacking many users at the same time), or attacks utilizing a pre-made rainbow table. – Paŭlo Ebermann Sep 2 '15 at 15:46
  • 1
    @PaŭloEbermann True, but majority of attacks are untargeted. Anybody who is a likely target of targeted attacks better use stronger passwords than the average user. As long as any cryptographic hash is being used, then making the password stronger does help. It is important to remember that there is more variation in the strength of passwords than there is variation in the strength of password hashes. An average password protected with the best password hash can be broken faster than a strong password protected with an unsalted MD5 hash. – kasperd Sep 2 '15 at 19:32

FIPS 140-2 does not list password hashing algorithms. If you actually need to use FIPS 140-2 validated algorithm, you need to find solutions that were validated by NIST for your required compliance level.

You probably need to verify this with a FIPS auditor, but PBKDF2 has implementations like PBKDF2-HMAC-SHA256 or 512 for instance. That could be regarded as compliant as the implementation is using SHA256 or 512.

| improve this answer | |
  • But, is that needed? Won't it suffice to use SHA-512? It's salted with a random number from a secure random generator. – John Assymptoth Aug 31 '15 at 17:33
  • 1
    No it will not. Such comments may result in Tom Leek's big brother trying to bite you. Have a look at the blog post I wrote about the goals of password hashing: security.blogoverflow.com/2013/09/about-secure-password-hashing – Lucas Kauffman Aug 31 '15 at 17:37
  • Lucas, this means that I can be FIPS certified independently of the password-hashing algorithm I use, as no password hashing algorithms are used in the FIPS-specification? – John Assymptoth Sep 1 '15 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.