Do FIPS 140-2 or related documens specify how to protect users' passwords with encryption? Are there any well known schemas for storing passwords in lossless manner and lossy manner?
3
-
1I'm not sure what lossy password storage would even be for. :)– Royce WilliamsCommented Apr 9, 2021 at 20:05
-
@RoyceWilliams Sometimes you just want to authenticate users yourself, so you can use just a hash of the password (or some other clever schema that I am asking about), lossy. But sometimes you need to store a password so that you can use it to authenticate to 3rd party, lossless.– wilxCommented Apr 10, 2021 at 4:05
-
1"authenticate to 3rd party" -- you use tokens for that. Or, you are taking about the difference between hashing a password or encrypting a password to pass on, in plaintext, to a 3rd party. If that's what you mean, then you've used "lossy/lossless" incorrectly.– schroeder ♦Commented Apr 10, 2021 at 20:57
Add a comment
|
1 Answer
FIPS 140-2 defines standards for cryptographic modules, and related standards specify permitted algorithms which can be validated. Typically, in these environments, the algorithm used for hashing passwords would be PBKDF2, since that's the only approved key-derivation function of that type. For symmetric encryption, you would use AES, and I would recommend either the GCM or CCM modes, because they have integrity built in.
Because AES-GCM has catastrophic failure with nonce reuse and the nonce size is not large enough to be picked at random securely, you should use a key-derivation function to derive a new key and nonce for each encryption.
Note that if you don't have regulatory requirements to adopt the FIPS 140-2 technologies, there are other, better algorithms that you should use instead. Scrypt or Argon2 are much better password hashing functions because they are memory hard; that is, in addition to the CPU cost, they also have a memory cost, making it harder for attackers to use GPUs or ASICs for this purpose. If your code will run on architectures that don't have hardware AES acceleration, then you may prefer to use ChaCha20-Poly1305 to protect your data, since software AES implementations can be vulnerable to side channel attacks, and ChaCha is much faster on those systems anyway. For systems with hardware AES acceleration, AES-GCM is probably a fine choice regardless of regulatory requirements.
Of course, as I mentioned, Scrypt, Argon2, and ChaCha aren't approved for government usage, so if you do have regulatory requirements, you'll have to stick with PBKDF2 and AES.
Ideally you will use a standard library for this that combines these primitives in a secure way so that you don't have to think about how to use them correctly.
