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 ?

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

  • 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_
    Commented Nov 22, 2018 at 15:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .