4 ms·

Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and preve

by lukevp 5y ago

Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert issuance and installing their own root CA is easily doable). Another issue is that improper logging on the server (or depending on the implementation, even intermediate load balancers) could accidentally leak the plaintext password. Client side hashing is a much better solution to this, and if it’s a native browser supported protocol, it would even work without JS.

ncann 5y ago
How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?
- notfed 5y ago
  There are answers to this. I asked myself this a few years ago, which led recursively to new tricky questions. I eventually solved the tree of the questions: I designed myself into a solution that I later realized was essentially an asymmetric PAKE (e.g., analogous to OPAQUE). So, an attempt to solve your question eventually leads to using an asymetric PAKE. But, this is way, way more complex. You'd really have to squint your eyes to believe that the diminishing returns are worth it.
axiosgunnar 5y ago
Your suggestion is vulnerable to the https://en.m.wikipedia.org/wiki/Pass_the_hash https://en.m.wikipedia.org/wiki/Pass_the_hash attack. Your suggestion is basically going back to the days where databases stored plaintext passwords in the database, just that the plaintext happens to be a hash.
lixtra 5y ago
> If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. Shouldn’t it be a proper challenge/response? Otherwise the hash is barely better than the password.
jeroenhd 5y ago
What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. If a criminal can do a MitM, they can substitute the Javascript that's hashing your password with all the nonces and salts and peppers you add to it and send the password anyway. If you just hash the password, the hash becomes the password. You're not solving the problem that way, you're just switching around definitions. There is an alternative that's supported in most platforms, and that's WebAuthn. Not even a need for a password automatic secure handshakes and with the right protocols, the keys differ per site so they're very hard to spoof through phishing. You can achieve much of the same thing with client TLS certificates, but the UX for that is even worse than the UX for HTTP Basic.
- staticassertion 5y ago
  > What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. To that one site. But users reuse passwords and if a criminal only has a hash they can't reuse it across sites.
  - jeroenhd 5y ago
    But the attacker controls the TLS connection already, so they'll just strip out the hashing functionality or send a piece of JS to steal the password directly from the password field. It's not that I don't understand where you're coming from (I once almost started writing such a library a few years back!), but I just can't think of a threat model where this makes sense. That's also what moved me away from working on such a system. To me, this approach feels like an attempt to recreate software-only U2F, but outside the browser. I don't think client side code can fix these problems. It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain.
    - staticassertion 5y ago
      I don't know why people are assuming the attacker: A) Controls the code running the auth API B) Controls the javascript As if that's the common attack. The common attack is that the attacker has a read on the hash, either through injection vulnerabilities or other leaks. Your attacker, as described, has remote code execution on a server that hosts the auth API and the Javascript in one place. That is a very specific, powerful attacker! > but I just can't think of a threat model where this makes sense 1. An attacker has CSRF and can trick your code into sending the hash to them. This significantly reduces the harm of that attack. 2. An attacker has an injection vulnerability giving them read access to hashes ie: sql injection, perhaps the most significant and relevant attack to discuss with passwords. 3. An attacker takes advantage of a timing attack, bruteforcing the server and measuring response times to leak its value. They can now only leak the hashed value, which is going to take way longer to leak and doesn't expose their password. And more! This defense tackles what are very very arguably the major threats to consider with regards to password security (they're the big ones in OWASP top 10). > It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain. You can significantly reduce harm and attack surface with all of 3 lines in your frontend code. salt = hash(username + static_salt) password_hash = pbkdf2(plaintext_password, salt) it's trivial to implement this. I'll grant you that PAKEs may be more complex to implement today, but even if we talk about a very basic implementation of client side hashing I think there's obvious value.

by lukevp 5y ago

ncann 5y ago

How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?

notfed 5y ago
There are answers to this. I asked myself this a few years ago, which led recursively to new tricky questions. I eventually solved the tree of the questions: I designed myself into a solution that I later realized was essentially an asymmetric PAKE (e.g., analogous to OPAQUE). So, an attempt to solve your question eventually leads to using an asymetric PAKE. But, this is way, way more complex. You'd really have to squint your eyes to believe that the diminishing returns are worth it.

axiosgunnar 5y ago

Your suggestion is vulnerable to the https://en.m.wikipedia.org/wiki/Pass_the_hash https://en.m.wikipedia.org/wiki/Pass_the_hash attack. Your suggestion is basically going back to the days where databases stored plaintext passwords in the database, just that the plaintext happens to be a hash.

lixtra 5y ago

> If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. Shouldn’t it be a proper challenge/response? Otherwise the hash is barely better than the password.

jeroenhd 5y ago

What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. If a criminal can do a MitM, they can substitute the Javascript that's hashing your password with all the nonces and salts and peppers you add to it and send the password anyway. If you just hash the password, the hash becomes the password. You're not solving the problem that way, you're just switching around definitions. There is an alternative that's supported in most platforms, and that's WebAuthn. Not even a need for a password automatic secure handshakes and with the right protocols, the keys differ per site so they're very hard to spoof through phishing. You can achieve much of the same thing with client TLS certificates, but the UX for that is even worse than the UX for HTTP Basic.

staticassertion 5y ago
> What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. To that one site. But users reuse passwords and if a criminal only has a hash they can't reuse it across sites.
- jeroenhd 5y ago
  But the attacker controls the TLS connection already, so they'll just strip out the hashing functionality or send a piece of JS to steal the password directly from the password field. It's not that I don't understand where you're coming from (I once almost started writing such a library a few years back!), but I just can't think of a threat model where this makes sense. That's also what moved me away from working on such a system. To me, this approach feels like an attempt to recreate software-only U2F, but outside the browser. I don't think client side code can fix these problems. It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain.
  - staticassertion 5y ago
    I don't know why people are assuming the attacker: A) Controls the code running the auth API B) Controls the javascript As if that's the common attack. The common attack is that the attacker has a read on the hash, either through injection vulnerabilities or other leaks. Your attacker, as described, has remote code execution on a server that hosts the auth API and the Javascript in one place. That is a very specific, powerful attacker! > but I just can't think of a threat model where this makes sense 1. An attacker has CSRF and can trick your code into sending the hash to them. This significantly reduces the harm of that attack. 2. An attacker has an injection vulnerability giving them read access to hashes ie: sql injection, perhaps the most significant and relevant attack to discuss with passwords. 3. An attacker takes advantage of a timing attack, bruteforcing the server and measuring response times to leak its value. They can now only leak the hashed value, which is going to take way longer to leak and doesn't expose their password. And more! This defense tackles what are very very arguably the major threats to consider with regards to password security (they're the big ones in OWASP top 10). > It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain. You can significantly reduce harm and attack surface with all of 3 lines in your frontend code. salt = hash(username + static_salt) password_hash = pbkdf2(plaintext_password, salt) it's trivial to implement this. I'll grant you that PAKEs may be more complex to implement today, but even if we talk about a very basic implementation of client side hashing I think there's obvious value.