10 ms·

Wow, it's quite disheartening to read some of the comments here. Let's try something shall we: - open up private browsing - press F12 (or however you get the

Wow, it's quite disheartening to read some of the comments here. Let's try something shall we: - open up private browsing - press F12 (or however you get the developer console on a mac) and go to the networking tab - go to gmail.com say - enter your gmail credentials - look at the post request generated, and at the request tab, it will contain your password in plain text So passwords don't get hashed on transit, this is why having HTTPS is so crucial, which is to prevent someone in the middle (say when you connect to an open Starbucks wifi) from sniffing out your unencrypted password. The password on the server side initially can be unencrypted before it gets hashed to be stored into the database. So in this instance, the password in the database is hashed, but there is a small period where the password is plain text in memory. For a site called hacker news, it's really sad how little people here know about hacking.

bzb4 6y ago
And that’s because you’re knowledgeable about the subject. You’ll see many people here and everywhere being assertive about things that are wrong and you’ll believe those people because you don’t know anything about the subject.
edwardr 6y ago
As an alternative to this checkout TozID. The premise of their authentication model is to avoid sending the password all together and use public key crypto to sign and verify requests between the client and the auth server. https://tozny.com/tozid/ https://tozny.com/tozid/
- jialutu 6y ago
  Nice, thanks for this! I also found out that protonmail doesn't seem to send the password in plain text in the post request itself. Really keen to see how they do it as well.
- arghwhat 6y ago
  Note that such system only provides you benefit if the client-implementation is to be trusted. E.g., if your user-agent does it all for you, you could consider it trusted, but if all the code is provided by the "untrusted" service-provider that you won't want to see your password, it ends up just being for show. Similar situation with ProtonMail: As long as you use the clients shipped by them (webmail, app), all of the security hinges on nothing but a promise. Their app can read the passwords and keys as much as it wants.
arghwhat 6y ago
> So passwords do get I think you meant "don't get" Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. There are protocols like SRP to do it securely, but it's non-trivial. And remember that such protocol is only useful if you trust the client implementation—it's kind of pointless for a third-party webpage or app. Use randomized per-site password. Solves everything.
- jialutu 6y ago
  Thanks, corrected :)
- gpm 6y ago
  > Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any. It's definitely non-standard though.
  - Zimahl 6y ago
    Isn't the main security feature of hashing that you hash against a salt and that no one but the server knows the salt? Once you send the salt to the client (and anything on the client should be considered insecure) you give the ability to generate lookup tables for common passwords. Without the salt it's much harder to brute-force the password.
    - fhars 6y ago
      No, the salt can be public (it was on Unix machines before the invention of /etc/shadow). The important thing is that it is unique per password, so that Hash(Salt#Password) is unique even if two passwords happen to be the same.
    - nikisweeting 6y ago
      Just use a different salt on the client and server. (and potentially even a different salt for each client)
eddieplan9 6y ago
Of course it’s OK the authentication system can read the password! What is so wrong on both technical and ethical levels is that the password entered into some data pipeline for machine learning. God knows what else they do with the cleartext passwords.
masonhensley 6y ago
I had a junior QA discover this while working at a Fortune 50... everything ground to a halt for two days until everyone (team of 20) was assured during a handful of meetings that this is how browsers work and why we use HTTPS. I appreciate they where trying to protect passwords & promote security, but it definitely caught me off guard that this wasn't widely understood.
ssalazar 6y ago
HTTPS is critical yes. If hash(password) is sent over HTTP in plaintext, then hash(password) can just be used in a replay attack. You shouldn't be sending passwords in any form over unencrypted HTTP, and there isnt a clear case for hashing or obscuring the password over HTTPS.
- avianlyric 6y ago
  Pretty clear case for not hashing however. Hashing the password on the client limits the password entropy to entropy of hash you generate. Any addition entropy in the original password is thrown away. Also naive hashing in the client just turns the hash into your password, all of the standard issues of transmitting passwords still exists (such as replay attacks as you mention).
  - lordlimecat 6y ago
    Entropy is defined by the password. The hash is deterministic.
    - xondono 6y ago
      Maximum entropy is defined by the password, the hash can reduce it.
      - MiroF 6y ago
        As long as the entropy of the client hash and of the server hash is the same, I still fail to see how this is a problem.
        xondono 6y ago
        AFAIK there isn’t a good reason to do that. To be useful the hash should turn your password into a OTP, at which point it’s no longer a hash
        6y ago
tootie 6y ago
Yup. I vaguely recall having to include something like this for a site I built years ago. I didn't code the filter myself, but I remember the feature request that usernames and passwords be filtered based on a profanity list. Users weren't blocked, they would just get "you can't do that" response. The passwords were inspected in memory as part of the request process after HTTPS decryption and before running through the digest function and sent to the DB.
benbou09 6y ago
Interesting, but did you really have to be condescending? On top of this, not everyone here is a hacker and not every hacker is a computer security expert.

bzb4 6y ago

And that’s because you’re knowledgeable about the subject. You’ll see many people here and everywhere being assertive about things that are wrong and you’ll believe those people because you don’t know anything about the subject.

edwardr 6y ago

As an alternative to this checkout TozID. The premise of their authentication model is to avoid sending the password all together and use public key crypto to sign and verify requests between the client and the auth server. https://tozny.com/tozid/ https://tozny.com/tozid/

jialutu 6y ago
Nice, thanks for this! I also found out that protonmail doesn't seem to send the password in plain text in the post request itself. Really keen to see how they do it as well.
arghwhat 6y ago
Note that such system only provides you benefit if the client-implementation is to be trusted. E.g., if your user-agent does it all for you, you could consider it trusted, but if all the code is provided by the "untrusted" service-provider that you won't want to see your password, it ends up just being for show. Similar situation with ProtonMail: As long as you use the clients shipped by them (webmail, app), all of the security hinges on nothing but a promise. Their app can read the passwords and keys as much as it wants.

arghwhat 6y ago

> So passwords do get I think you meant "don't get" Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. There are protocols like SRP to do it securely, but it's non-trivial. And remember that such protocol is only useful if you trust the client implementation—it's kind of pointless for a third-party webpage or app. Use randomized per-site password. Solves everything.

jialutu 6y ago
Thanks, corrected :)
gpm 6y ago
> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes. I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any. It's definitely non-standard though.
- Zimahl 6y ago
  Isn't the main security feature of hashing that you hash against a salt and that no one but the server knows the salt? Once you send the salt to the client (and anything on the client should be considered insecure) you give the ability to generate lookup tables for common passwords. Without the salt it's much harder to brute-force the password.
  - fhars 6y ago
    No, the salt can be public (it was on Unix machines before the invention of /etc/shadow). The important thing is that it is unique per password, so that Hash(Salt#Password) is unique even if two passwords happen to be the same.
  - nikisweeting 6y ago
    Just use a different salt on the client and server. (and potentially even a different salt for each client)

eddieplan9 6y ago

Of course it’s OK the authentication system can read the password! What is so wrong on both technical and ethical levels is that the password entered into some data pipeline for machine learning. God knows what else they do with the cleartext passwords.

masonhensley 6y ago

I had a junior QA discover this while working at a Fortune 50... everything ground to a halt for two days until everyone (team of 20) was assured during a handful of meetings that this is how browsers work and why we use HTTPS. I appreciate they where trying to protect passwords & promote security, but it definitely caught me off guard that this wasn't widely understood.

ssalazar 6y ago

HTTPS is critical yes. If hash(password) is sent over HTTP in plaintext, then hash(password) can just be used in a replay attack. You shouldn't be sending passwords in any form over unencrypted HTTP, and there isnt a clear case for hashing or obscuring the password over HTTPS.

avianlyric 6y ago
Pretty clear case for not hashing however. Hashing the password on the client limits the password entropy to entropy of hash you generate. Any addition entropy in the original password is thrown away. Also naive hashing in the client just turns the hash into your password, all of the standard issues of transmitting passwords still exists (such as replay attacks as you mention).
- lordlimecat 6y ago
  Entropy is defined by the password. The hash is deterministic.
  - xondono 6y ago
    Maximum entropy is defined by the password, the hash can reduce it.
    - MiroF 6y ago
      As long as the entropy of the client hash and of the server hash is the same, I still fail to see how this is a problem.
      - xondono 6y ago
        AFAIK there isn’t a good reason to do that. To be useful the hash should turn your password into a OTP, at which point it’s no longer a hash
        6y ago

tootie 6y ago

Yup. I vaguely recall having to include something like this for a site I built years ago. I didn't code the filter myself, but I remember the feature request that usernames and passwords be filtered based on a profanity list. Users weren't blocked, they would just get "you can't do that" response. The passwords were inspected in memory as part of the request process after HTTPS decryption and before running through the digest function and sent to the DB.

benbou09 6y ago

Interesting, but did you really have to be condescending? On top of this, not everyone here is a hacker and not every hacker is a computer security expert.