My users all have strong (80-bit true entropy) passwords. How do I know that? Because my imaginary website randomly generates the passwords for them (client-side). In that context, could you explain why it would be a problem to store them as plain unsalted hashes (either MD5, SHA1, or SHA256).
Asked
Active
Viewed 372 times
0
-
3It is really dangerous to generate passwords client-side. The hacker could detect a logic in this 'random' generation and break into most of the account. This should be - at least - server side. – Xavier59 Jul 01 '16 at 10:44
-
Possible duplicate of Why are salted hashes more secure for password storage? – eol Jul 01 '16 at 10:47
-
"Client-side" = no, you really don't know anything. – Oleg V. Volkov Jul 01 '16 at 14:09
-
1Note a dupe of "Why are salted hashes more secure for password storage?" as using cryptographically secure random passwords changes the need for salt. – Neil Smithline Jul 01 '16 at 15:08
2 Answers
3
Such strong passwords can be safely stored unsalted with a fast algorithm like SHA256, there is no problem in that.
The problems are different, you have to trust the client, the secure transportation to the server, and you have to make sure that the generated passwords are indeed unpredictable.
martinstoeckli
- 5,279
- 2
- 29
- 32
3
Sufficiently long passwords generated by a secure random number generator hashed by an algorithm with long output (at least 128 bit) and no known weakness (at least SHA256) will become infeasible to bruteforce (either against a single hash or compute a useful rainbow table) and salting will not be necessary.
Your description of your implementation doesn't satisfy the italic points. The password should contain enough entropy to deter bruteforcing. It should at least be 128-bits these days. Also, there's no way to get true randomness in a browser without non-standard browser extensions*. Naively using a PRNG does not give you very random numbers.
Edit:
* This is now possible with the Web Cryptography API, but any wrapper library that falls back to other ways of generating random numbers must be used with care.
billc.cn
- 3,936
- 1
- 18
- 25
-
There is an experimental JavaScript API meant to provide cryptographic random number generation in JavaScript, see this answer, and 80 bits password seems generally considered good enough. However, from a practical point-of-view, I'm still wondering how the OP expects his users to remember cookies off the top of head... – WhiteWinterWolf Jul 02 '16 at 08:23