3 ms·

> [0] of course, there is a chance that you just discovered a hash collision, but that is exceedingly unlikely. It also means that Gab would have accepted 'pass

> [0] of course, there is a chance that you just discovered a hash collision, but that is exceedingly unlikely. It also means that Gab would have accepted 'password' as the password for that user anyway, even if the string they typed in was 'warblerer' (which it would also accept). I don't think password policy enforcement can be reasonably done after the hashing. You cannot apply password rules as information about length and specific characters is lost; applying a blacklist would also be exceedingly expensive as you'd need to hash each word in your list with the selected salt.

tsimionescu 6y ago
I don't understand how your comment relates to what you are quoting. Password policy enforcement is done on the plain text password, during initial account creation or during a password change workflow. Then, the password and salt are hashed and the result and the salt are stored. When the user tries to login they then provide the plaintext password; the salt is retrieved, it is added to the password, the result is hashed, and the hash is compared to the stored hash. Since the space of all passwords is larger than the space of all hashes, there is a theoretical possibility that the user can provide a different password than the original plaintext, and this new plaintext + the salt happens to have the same hash, so the login system (which has no idea what the original plaintext was) will accept it. With any halfway decent cryptographic hashing function this is less likely than winning every lottery in the world at once with the same ticket.
- lultimouomo 6y ago
  Let's assume that the Gab user used a long and complicated password, that happened to hash-collide with "password". How do you know that Gab would have accepted "password" as a password? All we know is that it accepted the long and complicated one. This is obviously moot, as a collision is exceedingly unlikely in this case, but still.

tsimionescu 6y ago

I don't understand how your comment relates to what you are quoting. Password policy enforcement is done on the plain text password, during initial account creation or during a password change workflow. Then, the password and salt are hashed and the result and the salt are stored. When the user tries to login they then provide the plaintext password; the salt is retrieved, it is added to the password, the result is hashed, and the hash is compared to the stored hash. Since the space of all passwords is larger than the space of all hashes, there is a theoretical possibility that the user can provide a different password than the original plaintext, and this new plaintext + the salt happens to have the same hash, so the login system (which has no idea what the original plaintext was) will accept it. With any halfway decent cryptographic hashing function this is less likely than winning every lottery in the world at once with the same ticket.

lultimouomo 6y ago
Let's assume that the Gab user used a long and complicated password, that happened to hash-collide with "password". How do you know that Gab would have accepted "password" as a password? All we know is that it accepted the long and complicated one. This is obviously moot, as a collision is exceedingly unlikely in this case, but still.