4 ms·
> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Li
by ajross 3y ago
> Also not storing hashes of passwords, because then it wouldn't matter what the input is.
That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.
- TacticalCoder 3y agoIs it a slow sunday for me or... If you hash the password on the client and send the hash then hash is the password. And if you then have, for example, a DB leak with username and hashes, you don't need the password anyway because you can just send the hash and log in? (but then it's sunday and I need more coffee so I may be wrong)
- gvx 3y agoThat is correct. The client sends the encrypted (via HTTPS) but not hashed password to the server, both for changing your password and checking your password. So the server receives the password in plaintext but shouldn't store it. Whatever the client sends to the server, an attacker can send too.
- andy81 3y agoYou're not the first to come up with that exploit- https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash
- deleted 3y ago[deleted]
- sevensevennine 3y agoDon't hash the password on the client. That just changes the password to the hash of the password. Parameterize the SQL on the server instead of concatenating strings.
- hn_acker 3y agoIf you're using a third-party reverse proxy, then the third party will have access to the user's password. What's the simplest way to prevent the third-party from knowing the password? Would adding an encryption layer between the user and the actual website owner be both feasible and sufficient for the average website owner?
- Falmarri 3y agoDon't use reverse proxies you don't trust
- howrar 3y agoHow could the validation layer be affected by the presence of these substrings?
- ajross 3y agohttps://xkcd.com/327/ https://xkcd.com/327/