Hot answers tagged

57

PBKDF2 and other key stretching algorithms are meant to be slow and take the same amount of time whether the input password is correct or incorrect. To reduce computational load and latency for your user, the API should authenticate once via login credentials and issue a revokable or time-limited session token that is verified by a simple lookup.


23

Your starting point PBKDF2-HMAC-SHA-256 number of iterations desired = 1024 length of the salt in bytes = 16 length of the derived key in bytes = 4096 Algorithm Ok - PBKDF2-HMAC-SHA-256 is a solid choice, though if you're running on any modern 64-bit CPU, I would strongly recommend PBKDF2-HMAC-SHA-512 instead, because SHA-512 requires 64-...


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


20

If you don't mind me being blunt, I think you have a lot of misunderstandings in your post, and a lot of your conclusions seemed to be based on assumptions of what amount to conspiracy theories. First, let's be clear about a couple things, which I feel should be sufficient to dispel some of your assumptions and conspiracy theories: Google does not have the ...


19

The short answer is that PBKDF2 is considered appropriate and secure for password hashing. It is not as good as could be wished for because it can be efficiently implemented with a GPU; see this answer for some discussion (and that one for more on the subject). There are some arguable points, notably that PBKDF2 was designed to be a Key Derivation Function, ...


18

There's no exact answer, and here's why: Brute Force We start with a 128-bit symmetric key. Assuming the algorithm (e.g. AES) isn't yet broken, we have to look at power consumption. Assuming 100% efficient computation devices whose technology far exceeds any computer, ASIC, graphics card, or other key-cracking device you can dream up, there's a minimum ...


17

The confusion here is that there are two distinct kinds of key generation function, and people often say "key derivation function" without being explicit which one they mean (or even understanding there are two): Key-based key derivation functions Password-based key derivation functions A key-based derivation function like HKDF presupposes that the inputs ...


14

It's 2016, so it's well worth revisiting this 5 year-old question. There was a Password Hashing Competition conducted from 2013 to 2016, which accepted 24 submissions and selected Argon2 as its recommended password hashing algorithm. Everything that Thomas said about new vs. good still applies. As recently as February 2016 (after the end of the contest) ...


14

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing. You cannot setup a secure connection between client and server on your own, because there is no already ...


12

Apart from the fact you'd better not deploy custom crypto code anyway, you're reinventing the wheel. OpenPGP's string-to-key functionality is configurable and can be adjusted to your needs, while not losing compatiblity. I'm not discussing your choices in the number of cycles here, although they seem a little bit harsh. I'd recommend reading At what point ...


12

Not all KDFs are slow! Something like HKDF is extremely fast, and only involves a handful of invocations to the underlying PRF. KDFs are only slow when they're intended to convert a potentially low-entropy input—like a password—to a high-entropy output such as an encryption key or a password verifier. In this scenario, such functions are designed to be slow ...


10

There is no "sufficient" count, because user-chosen passwords can always be utterly weak, regardless of how well you coach them. You want the count to be the highest value that you can tolerate. Remember that increasing the iteration count mechanically increases the operational cost. So you will have to set the count to a value which is low enough for your ...


10

PBKDF2, scrypt and bcrypt are all configurable; they can be made as slow as you want. The limiting point is not the computer, but the user's patience. For example, suppose that the user will go irate if the password processing (e.g. to unlock an archive file) takes more than 6 seconds. If you use bcrypt only, then you can tune it up so that it takes 6 ...


10

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately. Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried ...


10

Upon initial user registration, generate a strong encryption key using a cryptographically secure pseudorandom number generator; this key will serve as the Data Encryption Key (DEK) to encrypt the user's data. But you don't want to store the DEK anywhere, at least in its plaintext form. You want to derive an encryption key from the user's password, using a ...


10

PBKDF2, or for that matter, any password hashing algorithm, is designed to be tunable so it can take a variable amount of time, depending on the security level to be desired. The amount of time it takes will be constant assuming the same parameters are taken, whether the password is correct or incorrect, since it's impossible to determine whether it's ...


9

The output length for PBKDF2 is what you need. But there are details. PBKDF2 is a Key Derivation Function: it produces a sequence of bytes of configurable length, whose intended purpose is to be used as keys for some symmetric encryption algorithm (or a MAC). So a first response is: if you want to use a symmetric encryption algorithm which expects, say, a ...


9

You shouldn't mess with the algorithm like this. I can't think about what the impact of this method is but it does scream insecurity. At the very least, it would allow an attacker to move roughly 256 times as fast since CRC is a relatively simple math function and then of course faster on the database part. You're a few whiteboard coding exercises away from ...


9

The attacker would have to crack the hashes in order to obtain the original passwords. Since PBKDF2 does multiple iterations of the same hash function, the act of cracking them would be significantly slower. The end result is that even weaker passwords are less likely be revealed, leading to a significantly lower percentage of successfully cracked passwords ...


8

8 bytes salt is fine, because that is globally unique when randomly generated, and that's the purpose of a salt: uniqueness. Too big is not an issue so estimating on the high side is fine, except you waste a little bit of storage. 32 bytes would be good for a derived key length (most hashing algorithms will output between 16 and 64 bytes, where 64 is just ...


8

that also prevents those in control of a server from brute-forcing that PIN? Essentially, no. No matter how securely it is set, or how strong the hash format is, once the server operators have a 6-digit hashed value they can brute-force it reasonably quickly. The short and predictable length of the PIN make it susceptible to brute-force attacks. You don'...


7

There is no "8 ms rule". There's an equation that was explained by Thomas Pornin (your first link) which stated in that example that for 32 bits of password quality and an attacker with 200 times the computing resources as your hashing system devoted to cracking hashes would complete the task in one month if it took you 8ms to run a hash. You need to adjust ...


7

I think you are finding this: 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 [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random bit generator and is ...


7

Is wrapping MD5 in PBKDF2 (or, for what it's worth, other secure hashing algorithms) something that safely can be done, or are there better approaches for dealing with old, insecure MD5 hashes? Yes, it is secure. You do not lose any security on this process. All these passwords would experience the same protection that the non-MD5 passwords have, given ...


7

Use the known, trusted algorithm over one that you've made yourself.** I can't speak for the entropy, but of course it will take more time if you have a sufficiently large number of iterations. It's just a matter of finding that number. That being said, I personally would not use your SHA256-based code. As has been said in what is probably my favourite ...


6

From Colin Percival's paper on scrypt: By using a key derivation function which requires 2^s cryptographic operations to compute, the cost of performing a brute-force attack against passwords with t bits of entropy is raised from 2^t to 2^(s+t) operations. 2,000,000 is about 2^21 iterations of SHA-512. In order for this to exceed the security offered by ...


6

It wouldn't add enough security to matter. It just means that the attacker has to compare with the stored hash after each iteration of the PBKFD2 function, rather than once after the (known) count. Since a comparison is much faster than an iteration (for any reasonable underlying hash function), this doesn't slow the attacker significantly. A slightly ...


6

The iterations are there to slow down the attacker. Let's suppose that the function is properly salted, so that the best an attacker can do is indeed trying out all potential passwords until a match is found. We define the password entropy to be equal to n bits if the best the attacker can do is, on average, to try 2n-1 passwords: the attacker knows which ...


6

If you are using the output for password hashing, then the output length: Must be no more than the native hash's output size SHA-1 is 20 bytes, SHA-224 is 28 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, SHA-512 is 64 bytes Must be no less than your risk tolerance. In practice, I'd say anything less than 20 bytes (SHA-1 native output size) is too ...


6

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken. ...


Only top voted, non community-wiki answers of a minimum length are eligible