3 ms·

To be honest, as far as I'm concerned there is no reason why Google or anyone should ever even have access to the plaintext passwords, let alone log them. The

by gdhbcc 7y ago

To be honest, as far as I'm concerned there is no reason why Google or anyone should ever even have access to the plaintext passwords, let alone log them. There Is no reason why we can't have 2 rounds of hashing, one client side and one server side. This way even if Google is malicious, it cannot know the actual password.

progval 7y ago
If you do a round of hashing on the client side, whatever is sent to the server becomes the actual secret needed to log in to the service. The only improvement is if you share your password between websites/services, which you shouldn't do. And a malicious service can change the javascript to exfiltrate the input password any time you log in.
- pfortuny 7y ago
  There is a better way: use an oracle-like device whose secret key is unavailable. See (shameful plug) http://thesybil.net http://thesybil.net Yes, it is academic but it should be everywhere. I improved it to perform client-side hashing and encryption but have had not the time to update the docs.
  - progval 7y ago
    I can't connect, the domain does not resolve. But sure, there are good solutions to this, like SCRAM. Unfortunately, there is not much point when the authentication code is controlled by the server (eg. JS served by a server)
    - pfortuny 7y ago
      Sorry, I always forget the order: http://thesibyl.net http://thesibyl.net
- gdhbcc 7y ago
  So worst case scenario it does nothing, and best case scenario it protects against a common security risk? Seems to me it should be standard...
- wyoung2 7y ago
  There are two classes of algorithms you can use to solve that problem: zero-knowledge proofs and Password Authenticated Key Exchanges (PAKE): https://en.m.wikipedia.org/wiki/Zero-knowledge_proof https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement In both, the client proves that it knows the password without ever sending it over the wire. The server also doesn’t store it in plaintext. In the algorithm I’m most familiar with (SRP6a) the plaintext password never leaves the client machine either on initial signup or on later password-based authentication, and what does transit the wire can be used neither to recover the password nor to replay the login attempt. You cannot break into the account just by passively watching the messages go back and forth. https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol One of the posts down-thread mentioned SCRAM, which I believe qualifies as a zero-knowledge proof algorithm, not a PAKE, but that’s about all I know about it. https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Au... One nice thing that falls out of a PAKE algorithm, as opposed to a zero-knowledge proof, is that you get a cryptographic key on both sides (thus the “key exchange” part of the acronym) that the peers can use with a symmetric encryption algorithm to communicate with each other. This then lets you construct things like TLS-SRP, which is a variant of TLS (ne SSL) that uses SRP to get the symmetric key instead of X.509 certificates and an entirely different key exchange algorithm: https://en.m.wikipedia.org/wiki/TLS-SRP Incidentally, the use of this sort of algorithm is why so many web sites now prompt for the user name and password on separate screens. There’s usually at least a two-way exchange involved where the user name goes to the server, which provides some bit of cryptographic hoo-hah, which then lets the client prove to the server in a separate exchange that it knows the password. This goes against old guidance to ask for both at once and to reject the login if either the user name or password are incorrect, which avoids giving an attacker a way to probe for valid user names. We lose that in the name of greater security goals.

by gdhbcc 7y ago

progval 7y ago

If you do a round of hashing on the client side, whatever is sent to the server becomes the actual secret needed to log in to the service. The only improvement is if you share your password between websites/services, which you shouldn't do. And a malicious service can change the javascript to exfiltrate the input password any time you log in.

pfortuny 7y ago
There is a better way: use an oracle-like device whose secret key is unavailable. See (shameful plug) http://thesybil.net http://thesybil.net Yes, it is academic but it should be everywhere. I improved it to perform client-side hashing and encryption but have had not the time to update the docs.
- progval 7y ago
  I can't connect, the domain does not resolve. But sure, there are good solutions to this, like SCRAM. Unfortunately, there is not much point when the authentication code is controlled by the server (eg. JS served by a server)
  - pfortuny 7y ago
    Sorry, I always forget the order: http://thesibyl.net http://thesibyl.net
gdhbcc 7y ago
So worst case scenario it does nothing, and best case scenario it protects against a common security risk? Seems to me it should be standard...
wyoung2 7y ago
There are two classes of algorithms you can use to solve that problem: zero-knowledge proofs and Password Authenticated Key Exchanges (PAKE): https://en.m.wikipedia.org/wiki/Zero-knowledge_proof https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement In both, the client proves that it knows the password without ever sending it over the wire. The server also doesn’t store it in plaintext. In the algorithm I’m most familiar with (SRP6a) the plaintext password never leaves the client machine either on initial signup or on later password-based authentication, and what does transit the wire can be used neither to recover the password nor to replay the login attempt. You cannot break into the account just by passively watching the messages go back and forth. https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol One of the posts down-thread mentioned SCRAM, which I believe qualifies as a zero-knowledge proof algorithm, not a PAKE, but that’s about all I know about it. https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Au... One nice thing that falls out of a PAKE algorithm, as opposed to a zero-knowledge proof, is that you get a cryptographic key on both sides (thus the “key exchange” part of the acronym) that the peers can use with a symmetric encryption algorithm to communicate with each other. This then lets you construct things like TLS-SRP, which is a variant of TLS (ne SSL) that uses SRP to get the symmetric key instead of X.509 certificates and an entirely different key exchange algorithm: https://en.m.wikipedia.org/wiki/TLS-SRP Incidentally, the use of this sort of algorithm is why so many web sites now prompt for the user name and password on separate screens. There’s usually at least a two-way exchange involved where the user name goes to the server, which provides some bit of cryptographic hoo-hah, which then lets the client prove to the server in a separate exchange that it knows the password. This goes against old guidance to ask for both at once and to reject the login if either the user name or password are incorrect, which avoids giving an attacker a way to probe for valid user names. We lose that in the name of greater security goals.