9 ms·

"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to

"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies somewhere. You are reliant on the server being a source of truth either way.

oconnore 5y ago
No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...
- thrashh 5y ago
  But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.
- gjsman-1000 5y ago
  > "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.
  - almost 5y ago
    Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password. But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.
    - gjsman-1000 5y ago
      I hope you are kidding. A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
      - masklinn 5y ago
        > A compromised website that was well designed Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it? > Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. That makes quite literally no sense, did you miss the entire thing and go off with whatever? The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
        garbagecoder 5y ago
        I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.
      - 5y ago
- michaelcampbell 5y ago
  > No, it would be much better to use a zero knowledge proof Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.
- geektips 5y ago
  Intresting idea, this kind implementation would have prevented password leak from something like Cloudbleed[0] [0] https://en.m.wikipedia.org/wiki/Cloudbleed https://en.m.wikipedia.org/wiki/Cloudbleed
- armchairhacker 5y ago
  idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).
  - xmprt 5y ago
    Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
    - mikea1 5y ago
      The salt-and-hash combo is how email logins worked for decades. The problem with this approach is that what you really want different salts, which requires that the server knows the plain text password.
    - armchairhacker 5y ago
      Yes, if an attacker compromises the database they can send the direct hash. The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
  - hnick 5y ago
    Then you either have: 1) A different salt each time, meaning the server must know your plaintext password to validate, or 2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.
- ibic 5y ago
  I don't think this is a major concern here, many websites pass username and password in plain text and rely on https for security (Just take a look at HN's log in form). If I'm not wrong, J2EE's login is implemented using plaint text also for password.
- rcxdude 5y ago
  Don't such methods require you to store the password in a non-hashed form on the server? That seems mostly worse than this approach, since now the passwords of all users are visible at rest and can be used directly as authentication. RADIUS I know commonly uses this approach and it always made me nervous having the passwords in plaintext.
dllthomas 5y ago
You've responded as if the bit you've quoted is advice to individual developers in the present context, but the topic of conversation was about extending browsers so that the standard login form would do this (... better than existing auth digest). If we did that and people were used to using the browser's built-in login dialog, and (as with https) we made it visible what security features were enabled, then a trivial server-side change wouldn't compromise user passwords.
- gjsman-1000 5y ago
  Right... that would be awesome. But it would still be susceptible to a hacker replacing it with a traditional login page with some logging... unless somehow you could prevent any traditional web pages from working.
  - madacol 5y ago
    And users WILL NOTICE before that happens Please, stop using those strawman arguments
    - dllthomas 5y ago
      Some users will notice. If we've succeeded to the point of "traditional login pages" being unusual and remarkable, many users will notice. Probably in any case some users will fail to notice. In any case, though, it seems likely to reduce the impact of a compromise.
    - gjsman-1000 5y ago
      I beg to differ. You'd be surprised how many users probably would not recognize any difference whatsoever as long as the hacker got things looking relatively identical.
remram 5y ago
Except you usually send the password once, and get back a cookie with a token that you present for the rest of your session (possibly to other endpoints/servers). Whereas with basic auth, the login/password keeps being sent.
gsich 5y ago
>If you are using HTTPS, you are equally as good as any other login form. Or equally as bad. TLS only protects you from sniffing, not the server seeing your password in cleartext.

oconnore 5y ago

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...

thrashh 5y ago
But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.
gjsman-1000 5y ago
> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.
- almost 5y ago
  Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password. But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.
  - gjsman-1000 5y ago
    I hope you are kidding. A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
    - masklinn 5y ago
      > A compromised website that was well designed Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it? > Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. That makes quite literally no sense, did you miss the entire thing and go off with whatever? The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
      - garbagecoder 5y ago
        I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.
    - 5y ago
michaelcampbell 5y ago
> No, it would be much better to use a zero knowledge proof Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.
geektips 5y ago
Intresting idea, this kind implementation would have prevented password leak from something like Cloudbleed[0] [0] https://en.m.wikipedia.org/wiki/Cloudbleed https://en.m.wikipedia.org/wiki/Cloudbleed
armchairhacker 5y ago
idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).
- xmprt 5y ago
  Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
  - mikea1 5y ago
    The salt-and-hash combo is how email logins worked for decades. The problem with this approach is that what you really want different salts, which requires that the server knows the plain text password.
  - armchairhacker 5y ago
    Yes, if an attacker compromises the database they can send the direct hash. The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
- hnick 5y ago
  Then you either have: 1) A different salt each time, meaning the server must know your plaintext password to validate, or 2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.
ibic 5y ago
I don't think this is a major concern here, many websites pass username and password in plain text and rely on https for security (Just take a look at HN's log in form). If I'm not wrong, J2EE's login is implemented using plaint text also for password.
rcxdude 5y ago
Don't such methods require you to store the password in a non-hashed form on the server? That seems mostly worse than this approach, since now the passwords of all users are visible at rest and can be used directly as authentication. RADIUS I know commonly uses this approach and it always made me nervous having the passwords in plaintext.

dllthomas 5y ago

You've responded as if the bit you've quoted is advice to individual developers in the present context, but the topic of conversation was about extending browsers so that the standard login form would do this (... better than existing auth digest). If we did that and people were used to using the browser's built-in login dialog, and (as with https) we made it visible what security features were enabled, then a trivial server-side change wouldn't compromise user passwords.

gjsman-1000 5y ago
Right... that would be awesome. But it would still be susceptible to a hacker replacing it with a traditional login page with some logging... unless somehow you could prevent any traditional web pages from working.
- madacol 5y ago
  And users WILL NOTICE before that happens Please, stop using those strawman arguments
  - dllthomas 5y ago
    Some users will notice. If we've succeeded to the point of "traditional login pages" being unusual and remarkable, many users will notice. Probably in any case some users will fail to notice. In any case, though, it seems likely to reduce the impact of a compromise.
  - gjsman-1000 5y ago
    I beg to differ. You'd be surprised how many users probably would not recognize any difference whatsoever as long as the hacker got things looking relatively identical.

remram 5y ago

Except you usually send the password once, and get back a cookie with a token that you present for the rest of your session (possibly to other endpoints/servers). Whereas with basic auth, the login/password keeps being sent.

gsich 5y ago

>If you are using HTTPS, you are equally as good as any other login form. Or equally as bad. TLS only protects you from sniffing, not the server seeing your password in cleartext.