11 ms·

This is ridiculous and unjustifiable. Hashed pqsswords in databases is the absolutely bare minimum nowadays. I would not only hash it already on the client sid

This is ridiculous and unjustifiable. Hashed pqsswords in databases is the absolutely bare minimum nowadays. I would not only hash it already on the client side, but have it also encoded with a freshly generated one-time-use public key on the client side every time it is being transmitted to my servers.

mod 4y ago
> Hashed pqsswords in databases is the absolutely bare minimum nowadays. And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then. I did it anyway, but it was just some homebrew blog I built.
FreakLegion 4y ago
Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security value, assuming you're doing everything else right, but do get some additional risk thanks to the extra moving part. There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.info/2018/10/25/should-your-next-web-based-lo....
- suriyaG 4y ago
  I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.
  - aobdev 4y ago
    They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).
  - FreakLegion 4y ago
    You're not wrong. To clearly delineate the two possibilities: 1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it. 2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash. In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.
xander158 4y ago
I think you're confusing storing user password for access to Okta vs storing passwords in Okta for access to other applications. If you're going to use Okta as a password manager and store passwords to access other applications you can't hash the password because it irreversible and you won't be able to get the real password to authenticate with the other application. So you must encrypt the passwords instead.
matsemann 4y ago
> This is ridiculous and unjustifiable. No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.
lelanthran 4y ago
> I would not only hash it already on the client side, How does hashing on the client side help?

mod 4y ago

> Hashed pqsswords in databases is the absolutely bare minimum nowadays. And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then. I did it anyway, but it was just some homebrew blog I built.

FreakLegion 4y ago

Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security value, assuming you're doing everything else right, but do get some additional risk thanks to the extra moving part. There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.info/2018/10/25/should-your-next-web-based-lo....

suriyaG 4y ago
I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.
- aobdev 4y ago
  They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).
- FreakLegion 4y ago
  You're not wrong. To clearly delineate the two possibilities: 1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it. 2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash. In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.

xander158 4y ago

I think you're confusing storing user password for access to Okta vs storing passwords in Okta for access to other applications. If you're going to use Okta as a password manager and store passwords to access other applications you can't hash the password because it irreversible and you won't be able to get the real password to authenticate with the other application. So you must encrypt the passwords instead.

matsemann 4y ago

> This is ridiculous and unjustifiable. No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.

lelanthran 4y ago

> I would not only hash it already on the client side, How does hashing on the client side help?