14

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?

John Assymptoth
  • 241
  • 2
  • 5

2 Answers2

21

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).

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Why isn't password-hashing covered by FIPS, Tom? Do you know? – John Assymptoth Aug 31 '15 at 17:40
  • 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
  • @TomLeek, I really want to use SHA-512 in my system (my company already implemented it). In your opinion, is this acceptable for password hashing? Or bcrypt/ PBKDF2 are the only way to go? – John Assymptoth Aug 31 '15 at 19:43
  • 1
    @JohnAssymptoth - Unsalted SHA-512 is little better than clear-text. You can read about password storage from the other bear [here](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846) – 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
  • @NeilSmithline Unsalted SHA-512 is much more secure than clear-text. Passwords stored as clear-text are insecure regardless of password strength. Passwords hashed with SHA-512 are secure as long as the password is strong. Any improvement beyond that only matters for mediocre passwords. Using a salt gives a lot of additional security for mediocre passwords at a very small cost. – kasperd Sep 01 '15 at 11:50
  • @kasperd the problem is that the border between mediocre and strong passwords (when using the definition "strong is secure when hashed with SHA-512") is in a region where common humans are not capable of memorizing them (quite more than the 44 bits of entropy in the [famous xkcd comic](https://xkcd.com/936/)). When it can't really be memorized, I would not call it "password" anymore. – Paŭlo Ebermann Sep 01 '15 at 12:50
  • @PaŭloEbermann Are you making a point about hash functions, or just complaining about which word he used? If you don't like word "password", then what do you suggest we use instead? – Mike Ounsworth Sep 01 '15 at 13:01
  • @PaŭloEbermann My point is that by using any cryptographic hash function, you are providing security for those users who are willing to memorize a strong password. By storing passwords unhashed, you are making the system insecure for everybody - even those who are making an effort to use it as securely as possible. That is a major difference, and claiming there is no difference between the two is incorrect. It's the difference between can be used securely, and cannot be used securely. – kasperd Sep 01 '15 at 13:28
  • @PaŭloEbermann But the cost of adding a salt while hashing is so minor and the added security is so significant, that actually using an unsalted hash for passwords is silly. Anything weaker than a salted cryptographic hash is inexcusable. Once you start moving beyond a salted cryptographic hash, you are approaching the realm of diminishing returns. The use of slower or iterated hashes does have a cost on the server side, which sometimes can be prohibitive, and the added security is less than what you got from the introduction of a salt. – kasperd Sep 01 '15 at 13:35
  • 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 02 '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 02 '15 at 19:32
5

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.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • 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: http://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 01 '15 at 11:30