7 ms·

I'm not an authentication system programmer, so this may be a silly question, but why do clients still send passwords to a server? Doesn't it make more sense to

by mnem 7y ago

I'm not an authentication system programmer, so this may be a silly question, but why do clients still send passwords to a server? Doesn't it make more sense to hash the username and password together with some sort of nonce/salt that's sent to the server for validation?

dwheeler 7y ago
> why do clients still send passwords to a server? Doesn't it make more sense to hash the username and password together with some sort of nonce/salt that's sent to the server for validation? You must ALWAYS hash the password (as a salted iterated cryptographic hash) on the server. You can in ADDITION also hash the password on the client end, but by itself that's not enough. The issue, as usual, comes down to "what is the attack you're trying to thwart"? If you hash on the client and not the server, then when (not if) the attacker manages to download the hashed password set, the attacker can create a modified client & send those hashes directly. If you don't hash on the server, it's exactly the same as storing passwords as clear text, because you're storing the data that an attacker can directly use to log in. You can also hash the password on the client IN ADDITION to the server. In that case, you're hiding from the server the actual password you type in. That's an improvement if you're sharing a single password across many services; in this case the attack you're trying to thwart is to prevent an attacker from actively capturing the password & trying to reuse the password on other systems. However, a much better idea is to not share a single password anyway, so it's not such a great thing.
- forty 7y ago
  Users reuse passwords. The main reason of not having your passwords in clear text is to protect them from that. At least when (not if as you noticed) your site is hacked (the same day this attacker download your password database probably), it has no other impact for your users that whatever can happen on your site (the attacker might be able to use the hashed passwords to log on your site but at this point you probably have bigger problems, given that someone is able to download your password database, and you are probably going to reset all those passwords anyway).
  - bastawhiz 7y ago
    This comment is full of many inaccuracies. Leaked hashed passwords still pose a risk to users on their other accounts that may use the same password. Hashing passwords prevents internal abuse and makes your site a much less juicy target (in addition to making leaks less disastrous). It also makes timing attacks far less feasible by enabling reasonable constant time comparison of the hashed password.
    - forty 7y ago
      I agree with what you are saying but I don't see how this conflicts to what I said.
itcrowd 7y ago
No it doesn't. In your example, the hash of the password becomes the new password (I.e. the new secret). The nonce/salt adds no security because it must be open to anyone attempting to authenticate.
- mnem 7y ago
  Surely it adds security in that an attacker cannot take that new password and use it on another site, even if the user re-used the underlying password?
  - itcrowd 7y ago
    Yes. It adds this feature. But only if you assume that the database was compromised or nefarious logging was enabled and no further access to the server was possible. Otherwise, the attacker can modify the JavaScript that is used by the client to perform the hashing (and remove/adjust the hashing function). To be clear, it would have prevented these logged passwords from impacting other websites if the true cause of the Robin Hood password reset was a logging issue. As a user, you can prevent this from happening either way by choosing strong, unique passwords for every service.
    - naniwaduni 7y ago
      This is still a meaningful improvement because accidentally making everything world-readable is in many cases easier than accidentally making everything world-writable.
    - mnem 7y ago
      It’s not assuming that has happened, it’s acknowledging it could happen (or any other bug that reveals database field, e.g. sql injection). It seems like it should just be a default practice - generally I try to design systems to fail safe, regardless of what causes that failure.
cyounkins 7y ago
Take a look at SRP: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
cellularmitosis 7y ago
some additional discussion: https://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon https://security.stackexchange.com/questions/53594/why-is-cl... I've also wondered why this isn't more common.
fortenforge 7y ago
If you hash the password on the client, then the hash essentially becomes the new password and you haven't solved anything. What you're looking for is a password authenticated key agreement in which one party authenticates to another without an eavesdropper learning any secret [1]. For whatever reason, no major websites use PAKEs today. [1] https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
- gdhbcc 7y ago
  But you have. It means even if you refuse your passwords elsewhere, only the website that was compromised is compromised.
  - rocqua 7y ago
    Really, that should be a salted hadh to really defend against password reuse.
  - allset_ 7y ago
    You can (and should) store the salt server-side. Moving the hashing to the client does not solve anything.
- mnem 7y ago
  I agree that it becomes the new password, but it prevents your own site becoming a contributor to credential stuffing attacks - if you don’t have the clear password transmitted to your systems, you can’t leak it accidentally in logs or through poor DB practices. I wonder why PAKEs haven’t caught on?
  - ynniv 7y ago
    Anything faster than bcrypt is practically clear text due to brute forcing, and running bcrypt inside the user interface is needlessly expensive. The common practice is to ensure that passwords are checked and discarded before they can be accidentally disclosed, or to avoid re-usable passwords altogether. Production logs should also only be accessible when there is a direct need. Sometimes this still fails, but it is relatively rare in well run sites.
DistractionRect 7y ago
If you take your idea and step through the login//authentication process, you'll find that what you're suggesting isn't really all that different to what is done normally. Overview, Scheme_0: - You send your unique identifier (email, username, etc) and password to the server in plaintext. - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+password+hashing scheme produce the stored hash - Server kicks back proper response In your scenario, Scheme_1: - You prehash the password locally and send your identifier + prehashed_password to the server - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+prehashed_password+hashing scheme produce the stored hash - Server kicks back proper response The only difference is the extra hashing step. From a security perspective, there is no gain; storing the prehashed_password from Scheme_1 in plaintext (e.g. logs) is no different than storing the password from Scheme_0 in plaintext.
- forty 7y ago
  The difference is that the password of scheme 0 is probably reused on many other websites. If for example you bcrypt the password client side, you at least don't have to deal with credentials that might work with all the other websites that your user is using.
  - twblalock 7y ago
    Password reuse on other sites is not your problem. It is your user's problem.
    - eropple 7y ago
      A fuck-you,-got-mine sort of approach to security doesn't work. It's everyone's problem. PAKEs are probably a good idea across the board.
  - stevenwliao 7y ago
    How do you bcrypt at an appropriate difficulty client-side? Consider that it probably needs to work on a mid-range Android phone from years ago.
rocqua 7y ago
That introduces additional complexity, and the password is already protected by https. As others have pointed out, if you go for complexity, there are better schemes. However, by avoiding the complexity you keep simpler client side code. Especially because this is standard, whilst doing extra stuff would involve doing your own crypto code.
- SlayAe 7y ago
  The only thing that you nées is a hash fonction. I think thé added complexity ils negligible on any modern System.
  - rocqua 7y ago
    Complexity of the code base. The computation of hashes client side requires quite a bit of custom code. Sending a plain text password is build into the browser.
  - cerberusss 7y ago
    Small tip: looking at the spelling errrors, I bet you're on mobile, and using the standard Google or iOS keyboard set to French. I constantly have to switch between English and my native language as well. But I found out that with Swiftkey (by Microsoft), you don't need to manually switch between two languages; you just configure two language at once and the software does autocorrect for both.

by mnem 7y ago

dwheeler 7y ago

> why do clients still send passwords to a server? Doesn't it make more sense to hash the username and password together with some sort of nonce/salt that's sent to the server for validation? You must ALWAYS hash the password (as a salted iterated cryptographic hash) on the server. You can in ADDITION also hash the password on the client end, but by itself that's not enough. The issue, as usual, comes down to "what is the attack you're trying to thwart"? If you hash on the client and not the server, then when (not if) the attacker manages to download the hashed password set, the attacker can create a modified client & send those hashes directly. If you don't hash on the server, it's exactly the same as storing passwords as clear text, because you're storing the data that an attacker can directly use to log in. You can also hash the password on the client IN ADDITION to the server. In that case, you're hiding from the server the actual password you type in. That's an improvement if you're sharing a single password across many services; in this case the attack you're trying to thwart is to prevent an attacker from actively capturing the password & trying to reuse the password on other systems. However, a much better idea is to not share a single password anyway, so it's not such a great thing.

forty 7y ago
Users reuse passwords. The main reason of not having your passwords in clear text is to protect them from that. At least when (not if as you noticed) your site is hacked (the same day this attacker download your password database probably), it has no other impact for your users that whatever can happen on your site (the attacker might be able to use the hashed passwords to log on your site but at this point you probably have bigger problems, given that someone is able to download your password database, and you are probably going to reset all those passwords anyway).
- bastawhiz 7y ago
  This comment is full of many inaccuracies. Leaked hashed passwords still pose a risk to users on their other accounts that may use the same password. Hashing passwords prevents internal abuse and makes your site a much less juicy target (in addition to making leaks less disastrous). It also makes timing attacks far less feasible by enabling reasonable constant time comparison of the hashed password.
  - forty 7y ago
    I agree with what you are saying but I don't see how this conflicts to what I said.

itcrowd 7y ago

No it doesn't. In your example, the hash of the password becomes the new password (I.e. the new secret). The nonce/salt adds no security because it must be open to anyone attempting to authenticate.

mnem 7y ago
Surely it adds security in that an attacker cannot take that new password and use it on another site, even if the user re-used the underlying password?
- itcrowd 7y ago
  Yes. It adds this feature. But only if you assume that the database was compromised or nefarious logging was enabled and no further access to the server was possible. Otherwise, the attacker can modify the JavaScript that is used by the client to perform the hashing (and remove/adjust the hashing function). To be clear, it would have prevented these logged passwords from impacting other websites if the true cause of the Robin Hood password reset was a logging issue. As a user, you can prevent this from happening either way by choosing strong, unique passwords for every service.
  - naniwaduni 7y ago
    This is still a meaningful improvement because accidentally making everything world-readable is in many cases easier than accidentally making everything world-writable.
  - mnem 7y ago
    It’s not assuming that has happened, it’s acknowledging it could happen (or any other bug that reveals database field, e.g. sql injection). It seems like it should just be a default practice - generally I try to design systems to fail safe, regardless of what causes that failure.

cyounkins 7y ago

Take a look at SRP: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

cellularmitosis 7y ago

some additional discussion: https://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon https://security.stackexchange.com/questions/53594/why-is-cl... I've also wondered why this isn't more common.

fortenforge 7y ago

If you hash the password on the client, then the hash essentially becomes the new password and you haven't solved anything. What you're looking for is a password authenticated key agreement in which one party authenticates to another without an eavesdropper learning any secret [1]. For whatever reason, no major websites use PAKEs today. [1] https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

gdhbcc 7y ago
But you have. It means even if you refuse your passwords elsewhere, only the website that was compromised is compromised.
- rocqua 7y ago
  Really, that should be a salted hadh to really defend against password reuse.
- allset_ 7y ago
  You can (and should) store the salt server-side. Moving the hashing to the client does not solve anything.
mnem 7y ago
I agree that it becomes the new password, but it prevents your own site becoming a contributor to credential stuffing attacks - if you don’t have the clear password transmitted to your systems, you can’t leak it accidentally in logs or through poor DB practices. I wonder why PAKEs haven’t caught on?
- ynniv 7y ago
  Anything faster than bcrypt is practically clear text due to brute forcing, and running bcrypt inside the user interface is needlessly expensive. The common practice is to ensure that passwords are checked and discarded before they can be accidentally disclosed, or to avoid re-usable passwords altogether. Production logs should also only be accessible when there is a direct need. Sometimes this still fails, but it is relatively rare in well run sites.

DistractionRect 7y ago

If you take your idea and step through the login//authentication process, you'll find that what you're suggesting isn't really all that different to what is done normally. Overview, Scheme_0: - You send your unique identifier (email, username, etc) and password to the server in plaintext. - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+password+hashing scheme produce the stored hash - Server kicks back proper response In your scenario, Scheme_1: - You prehash the password locally and send your identifier + prehashed_password to the server - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+prehashed_password+hashing scheme produce the stored hash - Server kicks back proper response The only difference is the extra hashing step. From a security perspective, there is no gain; storing the prehashed_password from Scheme_1 in plaintext (e.g. logs) is no different than storing the password from Scheme_0 in plaintext.

forty 7y ago
The difference is that the password of scheme 0 is probably reused on many other websites. If for example you bcrypt the password client side, you at least don't have to deal with credentials that might work with all the other websites that your user is using.
- twblalock 7y ago
  Password reuse on other sites is not your problem. It is your user's problem.
  - eropple 7y ago
    A fuck-you,-got-mine sort of approach to security doesn't work. It's everyone's problem. PAKEs are probably a good idea across the board.
- stevenwliao 7y ago
  How do you bcrypt at an appropriate difficulty client-side? Consider that it probably needs to work on a mid-range Android phone from years ago.

rocqua 7y ago

That introduces additional complexity, and the password is already protected by https. As others have pointed out, if you go for complexity, there are better schemes. However, by avoiding the complexity you keep simpler client side code. Especially because this is standard, whilst doing extra stuff would involve doing your own crypto code.

SlayAe 7y ago
The only thing that you nées is a hash fonction. I think thé added complexity ils negligible on any modern System.
- rocqua 7y ago
  Complexity of the code base. The computation of hashes client side requires quite a bit of custom code. Sending a plain text password is build into the browser.
- cerberusss 7y ago
  Small tip: looking at the spelling errrors, I bet you're on mobile, and using the standard Google or iOS keyboard set to French. I constantly have to switch between English and my native language as well. But I found out that with Swiftkey (by Microsoft), you don't need to manually switch between two languages; you just configure two language at once and the software does autocorrect for both.