1
$\begingroup$

Is it more secure to combine algorithms for password hashing, for example, Scrypt, Bcrypt, SHA-3, etc.? If an attacker wants to use dedicated hardware, he would need one for each algorithm. However, I know having multiple algorithms increases the probability of having bugs and leaks.

If having multiple algorithms for EACH password can create leaks, what about having different algorithms for different passwords: If the attacker only has hardware for Bcrypt, he can't brute force passwords hashed with Scrypt.

EDIT : By combining, I mean, hash2(hash1(hash0(password))). In the second paragraph, I mean hash0(P0), hash1(P1), hash2(P2), hash0(P3), hash1(P4), hash2(P5).

EDIT : What about hash0(P0), hash1(P0), hash0(P1), hash1(P1), ... ?

$\endgroup$
  • $\begingroup$ How would you combine them? Hash every password using all hashes and store all the hashes? Chain the hashes? ... something else? $\endgroup$ – SEJPM Jun 22 at 10:40
  • 2
    $\begingroup$ You seem to assume hardware acceleration is a magic bullet; it isn't. Pick a modern KDF and use an appropriate cost based on your threat assessment. You can further make stored hashes safer by using a secret pepper in addition to the salt. $\endgroup$ – Marc Jun 22 at 10:54
  • $\begingroup$ If an attacker only has one type of harware, it is much worse for him if I use another algorithm than if I use pepper, they can just run it multiple times, and it wont be much more slower for a normal user. Pepper is very slow for both, multiple algorithm is much much slower for the attacker. $\endgroup$ – moutonlapin28 Jun 22 at 12:35
  • $\begingroup$ It seems we have a different definition of the pepper, in my case, your definition of the pepper can't be used as it is end to end encryption. $\endgroup$ – moutonlapin28 Jun 22 at 12:47
  • 2
    $\begingroup$ The link I mentioned is pretty clear: a pepper is a long server-owned secret added to the plaintext password before hashing. Unlike a salt, it is not stored next to the hash and provides protection against leaks of the database contents (a common issue). Someone with just the hash and salt would have to brute force both the password and the pepper. With an appropriate length, no amount of hardware acceleration will help. $\endgroup$ – Marc Jun 22 at 12:59
1
$\begingroup$

The combination of different schemes may be somewhat advantageous with regard to certain custom hardware (ASICs), but I think that the disadvantages outweigh them.

  • I assume that there is some kind of fixed time that is acceptable to the user. Nobody will use a procedure where she or he has to wait several minutes. Modern password hashing schemes are characterized by the fact that they are not only time intensive, but also memory-hard. To put it simply, a vector is created in RAM in the time acceptable to the user. If less time is available, this vector is smaller. Splitting the acceptable time over several password hashing schemes results in less time to generate the vector for each single scheme. So the whole process becomes less memory-hard.

  • Password hashing schemes, like all cryptographic procedures, are potentially susceptible to side channel attacks. This applies, for example, to cache timing attacks. Several schemes offer more targets.

  • And as the questioner has already correctly pointed out, the susceptibility to bugs is greater with several schemes.

I would rather rely on one scheme such as Argon2id and spend all available time to make this method as memory-hard as possible.

| improve this answer | |
$\endgroup$

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.