3 ms·

Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether th

Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether there is processing or not. I guess what I'm asking is this: can someone walk me through the attack scenario? I don't really get it.

jakelazaroff 8y ago
Consider: Mallory wants to access Alice's account on a website. 1. Mallory enters Alice's username and a random password 2. Website sends back Alice's plaintext password to be checked client side 3. Mallory inspects network traffic and retrieves Alice's plaintext password It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other protection the site operator could implement.
- throwawaymath 8y ago
  Wait why is the password being sent back by the server to the client? Is that what the commenter originally meant? If that's the case I completely misunderstood what they meant by processing the password with JavaScript. What you've described is insane; I thought the critique was in regards to processing a password locally before sending it to the server (e.g. local hashing).
  - jakelazaroff 8y ago
    I believe so. This was the original description (emphasis mine): > I've even seen a website where the password is sent to the browser and the password checking happens in Javascript. i.e. the server sends the (plaintext or hashed) password to the client, and the client verifies it locally. Edit: the original commenter replied as a sibling to you: https://news.ycombinator.com/item?id=18382949 https://news.ycombinator.com/item?id=18382949
- jrockway 8y ago
  In the case I was talking about, it was even worse. The Javascript just set a GET param that said the password is OK. You can then log in as anyone with this method. As I recall, it did send you the plaintext password too, of course.

jakelazaroff 8y ago

Consider: Mallory wants to access Alice's account on a website. 1. Mallory enters Alice's username and a random password 2. Website sends back Alice's plaintext password to be checked client side 3. Mallory inspects network traffic and retrieves Alice's plaintext password It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other protection the site operator could implement.

throwawaymath 8y ago
Wait why is the password being sent back by the server to the client? Is that what the commenter originally meant? If that's the case I completely misunderstood what they meant by processing the password with JavaScript. What you've described is insane; I thought the critique was in regards to processing a password locally before sending it to the server (e.g. local hashing).
- jakelazaroff 8y ago
  I believe so. This was the original description (emphasis mine): > I've even seen a website where the password is sent to the browser and the password checking happens in Javascript. i.e. the server sends the (plaintext or hashed) password to the client, and the client verifies it locally. Edit: the original commenter replied as a sibling to you: https://news.ycombinator.com/item?id=18382949 https://news.ycombinator.com/item?id=18382949
jrockway 8y ago
In the case I was talking about, it was even worse. The Javascript just set a GET param that said the password is OK. You can then log in as anyone with this method. As I recall, it did send you the plaintext password too, of course.