5 ms·

It's a shame that password hashing isn't standardized. There should be a standard password box in html in which you can just call a function to pull out a sa

It's a shame that password hashing isn't standardized. There should be a standard password box in html in which you can just call a function to pull out a salted hash of a password. The attributes of the box could include options for password restrictions such as a minimum of 8 chars, etc. The fact that developers still need to write custom hashing algorithms in javascript is kind of ridiculous . edit: nevermind, I just realized this wouldn't work

j16sdiz 7y ago
This issue only affect those account resetted by admin.
manch23 7y ago
Its my understanding that the hashing should not be done client side, as that would expose the secret salt that is being used and reduce security?
- eropple 7y ago
  Password salts aren't secret. They are stored alongside a password hash because they're necessary to reconstruct the hash from the plaintext. If you look at a bcrypt string, for example, the salt's encoded in it. The problem is instead that now that the client-side hash is actually the password. (edit: some people use a "pepper" at the application level and apply it to all passwords, which might be kind of what you're thinking of? Buy you don't need to do this with modern key derivation algorithms. You can if you want, it just doesn't really matter much.)
- amalcon 7y ago
  That's not why (the salt does need to be secret secret), but it is true that the hashing should not be done client side. It's more because it doesn't actually accomplish a whole lot. The hash basically just becomes the password, so you'd need to hash it again on the server to get the same level of security.
eropple 7y ago
How would this work when you have to store the hash on a server? A hypothetical client-side hasher doing this means that an attacker would just...send the hash, acquired through nefarious means. Just as they'd send the password today. Server-side, that hash would be the password and that itself would need to be hashed before storage. I don't know why you're talking about "custom hashing algorithms", in JavaScript or elsewhere; you pull a bcrypt/scrypt/Argon2 library and use it.
- topmonk 7y ago
  Yea you're right. But what about this, the client uses the password as a seed to create a public/private key pair, and sends the public key to the server. If it is during password creation, the server stores this public key in relation to the user, otherwise verifies it. Then the server sends a challenge* and the client uses the private key to sign it and return a response. * actually the server would send the challenge ahead of time along with serving the web page
  - eropple 7y ago
    That sounds like PAKE. I'm not qualified to opine on that; it's above my pay grade. I can see a lot of implementation issues, though, if you wanted to make it a browser component outside the control of the developer.
comboy 7y ago
There is no client-side security. If you hash on the client side then that hash becomes the password and you have plain text password storage.
- odensc 7y ago
  You could just hash the hash that the client sends, no? Then you never know their password and it's still stored securely.
  - munk-a 7y ago
    If the client always hashes the password in the same way (no nonce or usage of encryption) then the password essentially becomes the hashed string with some extra clientside code you're burdened with forever. And since that same hashing will need to be done whenever they log in the hashing algorithm needs to be in the client side code sent to everyone... meaning an attacker would have a bit of obscurity in their way and just need to regenerate a rainbow table based off of your hashing algorithm to test common/weak passwords.
    - odensc 7y ago
      It's not about the security, it's about preventing side-channel leaks of the plain password (e.g. incorrectly sanitized logs or buffer overflows). Having a data breach of your site-specific hash is much better than leaking the user's password that an attacker could use on any website.
      - munk-a 7y ago
        Your site specific hash, if leaked into logs and generated using a fixed hashing algorithm, would just be a step of obscurity, a rainbow table generated according to that hashing algorithm would be able to extract the original typed password pretty reliably for use in compromising other accounts held by the individual on other sites. There are ways to actually add security above SSL but they require a per-session nonce. The most secure versions of these operate on some sort of out-of-band time-scrambling algorithm that's issued to users on an individual basis (usually a dongle) which is basically a nonce that's been pre-arranged a few years in advance, these can (if done correctly) provide all the security of on-demand generated nonces and physical keys combined. Fixed hashing algorithms add such a negligible amount of security that I'd prefer to avoid them due to the tech debt their existence incurs outweighing their advantage.
matthewmacleod 7y ago
I can’t think of any situation where password hashing should be happening on the client - that would eliminate a large part of the benefit.
- megous 7y ago
  The company not having any access to the plaintext password would already be a huge benefit. (many people are giving random companies access credentials to their e-mail, as it stands) Although that would be hard to enforce. They would only be able to screw users by allowing access to their own service if they were forced to provide a salt and only be able to get the hash. <input type=password salt=687161> would only return the salted and hashed value. But at html level, everything is possible and this would be hardly possible to enforce, aside from informing the user that they are typing a password into unsecure password field (hard to do, not to be fakeable, too). It would still be hackable, by bad actors by using a salt of a service they want to get pw for, but that would at least be detectable client side.
  - dbt00 7y ago
    If the salt is static, the hash becomes the password. Nobody does this. If the hash is dynamic, the password has to be stored in plaintext. Kerberos does something like this. Neither of these are better than the current state of the art. Read up on SRP for a public-key based system that does something like what you want. Third party data access should go through OAuth, not by sharing passwords to services.
    - megous 7y ago
      People share passwords, and use e-mail address to create accounts on all kinds of websites. Anything that would prevent the website's server from getting the plaintext password would be good. Salted hash is obviously not a plaintext password and can't be stuffed around to other services.
ReidZB 7y ago
Perhaps you'd be interested in reading about Secure Remote Password (SRP): https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... Copying the "layman's terms" from that page for your convenience... In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.
- topmonk 7y ago
  Thanks, I thought there should be something like this.
munk-a 7y ago
Thankfully people have realized this in settings like PHP leading them to drop the old suggested password hashing method... which at this point I can't recall, but it involved setting up salts manually and making sure you had a strong IV... which no common web devs would do. Now you've just got to call these two: https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-verify.php https://www.php.net/manual/en/function.password-verify.php and if you really want to tweak things you can, but the simple route is moderately secure
defanor 7y ago
Mere hashing indeed wouldn't be useful, but there's SCRAM, and it's standardized as one of HTTP authentication mechanisms (see RFC 7804). Edit: though perhaps it's worth noting that it won't force a server to store a password securely, but would facilitate it.
stunt 7y ago
Time to introduce a new Postgre data type. (:troll:)

j16sdiz 7y ago

This issue only affect those account resetted by admin.

manch23 7y ago

Its my understanding that the hashing should not be done client side, as that would expose the secret salt that is being used and reduce security?

eropple 7y ago
Password salts aren't secret. They are stored alongside a password hash because they're necessary to reconstruct the hash from the plaintext. If you look at a bcrypt string, for example, the salt's encoded in it. The problem is instead that now that the client-side hash is actually the password. (edit: some people use a "pepper" at the application level and apply it to all passwords, which might be kind of what you're thinking of? Buy you don't need to do this with modern key derivation algorithms. You can if you want, it just doesn't really matter much.)
amalcon 7y ago
That's not why (the salt does need to be secret secret), but it is true that the hashing should not be done client side. It's more because it doesn't actually accomplish a whole lot. The hash basically just becomes the password, so you'd need to hash it again on the server to get the same level of security.

eropple 7y ago

How would this work when you have to store the hash on a server? A hypothetical client-side hasher doing this means that an attacker would just...send the hash, acquired through nefarious means. Just as they'd send the password today. Server-side, that hash would be the password and that itself would need to be hashed before storage. I don't know why you're talking about "custom hashing algorithms", in JavaScript or elsewhere; you pull a bcrypt/scrypt/Argon2 library and use it.

topmonk 7y ago
Yea you're right. But what about this, the client uses the password as a seed to create a public/private key pair, and sends the public key to the server. If it is during password creation, the server stores this public key in relation to the user, otherwise verifies it. Then the server sends a challenge* and the client uses the private key to sign it and return a response. * actually the server would send the challenge ahead of time along with serving the web page
- eropple 7y ago
  That sounds like PAKE. I'm not qualified to opine on that; it's above my pay grade. I can see a lot of implementation issues, though, if you wanted to make it a browser component outside the control of the developer.

comboy 7y ago

There is no client-side security. If you hash on the client side then that hash becomes the password and you have plain text password storage.

odensc 7y ago
You could just hash the hash that the client sends, no? Then you never know their password and it's still stored securely.
- munk-a 7y ago
  If the client always hashes the password in the same way (no nonce or usage of encryption) then the password essentially becomes the hashed string with some extra clientside code you're burdened with forever. And since that same hashing will need to be done whenever they log in the hashing algorithm needs to be in the client side code sent to everyone... meaning an attacker would have a bit of obscurity in their way and just need to regenerate a rainbow table based off of your hashing algorithm to test common/weak passwords.
  - odensc 7y ago
    It's not about the security, it's about preventing side-channel leaks of the plain password (e.g. incorrectly sanitized logs or buffer overflows). Having a data breach of your site-specific hash is much better than leaking the user's password that an attacker could use on any website.
    - munk-a 7y ago
      Your site specific hash, if leaked into logs and generated using a fixed hashing algorithm, would just be a step of obscurity, a rainbow table generated according to that hashing algorithm would be able to extract the original typed password pretty reliably for use in compromising other accounts held by the individual on other sites. There are ways to actually add security above SSL but they require a per-session nonce. The most secure versions of these operate on some sort of out-of-band time-scrambling algorithm that's issued to users on an individual basis (usually a dongle) which is basically a nonce that's been pre-arranged a few years in advance, these can (if done correctly) provide all the security of on-demand generated nonces and physical keys combined. Fixed hashing algorithms add such a negligible amount of security that I'd prefer to avoid them due to the tech debt their existence incurs outweighing their advantage.

matthewmacleod 7y ago

I can’t think of any situation where password hashing should be happening on the client - that would eliminate a large part of the benefit.

megous 7y ago
The company not having any access to the plaintext password would already be a huge benefit. (many people are giving random companies access credentials to their e-mail, as it stands) Although that would be hard to enforce. They would only be able to screw users by allowing access to their own service if they were forced to provide a salt and only be able to get the hash. <input type=password salt=687161> would only return the salted and hashed value. But at html level, everything is possible and this would be hardly possible to enforce, aside from informing the user that they are typing a password into unsecure password field (hard to do, not to be fakeable, too). It would still be hackable, by bad actors by using a salt of a service they want to get pw for, but that would at least be detectable client side.
- dbt00 7y ago
  If the salt is static, the hash becomes the password. Nobody does this. If the hash is dynamic, the password has to be stored in plaintext. Kerberos does something like this. Neither of these are better than the current state of the art. Read up on SRP for a public-key based system that does something like what you want. Third party data access should go through OAuth, not by sharing passwords to services.
  - megous 7y ago
    People share passwords, and use e-mail address to create accounts on all kinds of websites. Anything that would prevent the website's server from getting the plaintext password would be good. Salted hash is obviously not a plaintext password and can't be stuffed around to other services.

ReidZB 7y ago

Perhaps you'd be interested in reading about Secure Remote Password (SRP): https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... Copying the "layman's terms" from that page for your convenience... In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.

topmonk 7y ago
Thanks, I thought there should be something like this.

munk-a 7y ago

Thankfully people have realized this in settings like PHP leading them to drop the old suggested password hashing method... which at this point I can't recall, but it involved setting up salts manually and making sure you had a strong IV... which no common web devs would do. Now you've just got to call these two: https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-verify.php https://www.php.net/manual/en/function.password-verify.php and if you really want to tweak things you can, but the simple route is moderately secure

defanor 7y ago

Mere hashing indeed wouldn't be useful, but there's SCRAM, and it's standardized as one of HTTP authentication mechanisms (see RFC 7804). Edit: though perhaps it's worth noting that it won't force a server to store a password securely, but would facilitate it.

stunt 7y ago

Time to introduce a new Postgre data type. (:troll:)