Hacker News Reader

Comment by ajross | Hacker News Reader

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

View on HN

Is 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)

That 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.

You're not the first to come up with that exploit-

https://en.wikipedia.org/wiki/Pass_the_hash

Don'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.

If 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?

Don't use reverse proxies you don't trust

How could the validation layer be affected by the presence of these substrings?

https://xkcd.com/327/

Reply on news.ycombinator.com