1

There are plenty of question addressing the "client / server : where to hash ?", but i have not found anything about my particular question : considering a server_salted_hash(client_salted_hash(password)), using HTTPS, What are the risks concerning hash collisions, or is there other even more serious risks than them ? (of course, considering

As I remember in school, and readings about security good practices, a main reason about not composing hash function is it "paradoxally" weaken it by potentially increasing the number of collisions, or easing reversing it.

Thus, I would like to know if there are any security flaws introduced by such a system ? (that wouldn't be if I hash only on backend)

Supposing I use salt on both hash, are there some combinations of hash you would recommend, or advise against ?

hl037_
  • 111
  • 3

1 Answers1

1

If you use the correct hash functions, chances of collisions are negligible. This remains the case if you hash repeatedly. The question Strength of multiple hash iterations? explains:

There's a catch: increasing n also slightly increases the odds that a random password gives the same result as the right password due to hash collisions, and is thus a false but accepted password; however that remain very unlikely, in the order of n·2−256 for practical values of n, and can be entirely ignored in practice.

I would recommend using a slow, well-known password hashing function, such as PBKDF2, scrypt, bcrypt, or Argon2.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • thanks for the answer, I intend to use SHA3 on client for speed, and argon 2 on server because it's slower and strong – hl037_ Nov 22 '18 at 15:04