3

Since slower is better and key stretching is an awesome way to increase security over potentially low entropy passwords, doesn't it make sense to use all three?

To be clear, this is about implementing a key stretching architecture for your software. I see a lot of disputes about which is best, but it seems to me - just use all three.

Blaze
  • 334
  • 3
  • 14
  • I doubt you would get any benefit from layering them like that. Also remember, that in hashing you can actually decrease the search space of a password by passing it though multiple hashes if any one of those hashing algorithms is weak in any respect. – Daisetsu Apr 22 '16 at 23:52
  • Be VERY careful about feeding output of hash function into bcrypt. bcrypt truncates its input at 72 bytes OR FIRST NUL BYTE. Meaning bcrypt("\x00foo") == bcrypt("\x00bar"). http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html – Z.T. Oct 09 '16 at 00:27

3 Answers3

11

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 seconds on your machine. But if you use PBKDF2 and scrypt and bcrypt in succession, then they will have to fit together in the 6-second budget, meaning that, in practice, you'll configure them with lower iteration counts, e.g. 2 seconds each. From that point of view, using three algorithms in succession is no better than one; what matter is the total time.

The point of this configurable slowness is that it makes things harder for the attacker; you want to choose an algorithm that makes each password guess as expensive as possible for the attacker. The attacker does not have necessarily the same hardware as you (e.g. he will likely try to use a GPU), so each algorithm may be more or less "good". The attacker can always buy a PC such as yours, and thus do in 6 seconds what you do in 6 seconds; however, the attacker may sometimes buy a more specialized hardware which will be better than yours for that specific task. This is especially the case with PBKDF2 and GPU. As a defender, you want to avoid such a situation. Thus, some algorithms are better than others, and, in the PBKDF2 / bcrypt / scrypt triad, one may assume that one algorithm is "stronger" in the sense explained above.

Therefore, using just that algorithm, alone and with its configuration adjusted so that it takes as much time as you can tolerate, will be optimal. By definition, using all three algorithms in succession cannot be as strong as that unique algorithm alone. In practice, this means that you should use bcrypt: the budget you spend on PBKDF2 is squandered security, since, for the same CPU usage on your machine, bcrypt would have provided more resistance (see this for some details about bcrypt vs scrypt, and that for even more details on password hashing in general).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
1

It is actually quite dangerous to do so. You could say you are adding strengths but in fact you are stacking weaknesses. PBKDF2 has no protection against GPUs for example, meaning those rounds are wasted effort on your server that the user/processes have to wait for but do not contribute as much to the security as bcrypt (or scrypt). Bcrypt has no protection against FPGAs. Scrypt is built to withstand both. It is therefor best to use the strongest function.

That said, NIST has stated that they advice PBKDF2 which technically is the weakest but it is probably good enough. They have always been ambivilent towards bcrypt though. Scrypt is the new kid on the block and therefor isn't as proven as the others.

Caen
  • 11
  • 1
0

Highly dependent. After a certain point encryption just doesn't become worth it. No matter how secure you can make it. Just because technique X is more secure than technique Y if the data ever gets stolen is a horrible argument for it because in the first place you should have had the proper security in place to make sure it couldn't be stolen in the first place. It means you're trying to solve a problem by answering another problem that is completely unrelated.

If your security vector is "If my hard drive gets stolen, how do I make sure that the contents on it are secure?" than this is even still a bad idea because the real answer is to have some sort of off hardware encryption key store so that if they steal the hardware including the hard drive, they can't decrypt it unless they guess the key. The universe would die by then if the encryption is just at a good enough level which most often than not using even just two of those in tandem does.

Remember, you have infinity possible keys. If you can guess infinity guesses in a reasonable time frame I'd be truly impressed.

Robert Mennell
  • 6,978
  • 1
  • 14
  • 38