6 ms·

Eh, if you're using TLS it really doesn't matter where you hash. There's a lot of arguments for not doing secure hashing and encryption in JavaScript

hvidgaard 10y ago
If I hash client side the server will never know my password. If the server hashes the password, that is effectively the same as storing the password in cleartext. /edit: Security wise sending the password, means you trust the server to handle the password correctly. For all we know it stores the plaintext password. If we send the hash, we KNOW that it does not store the password. It's an important distinction to make in real world systems. No matter how much best practices dictates to not reuse passwords, it happens as long as humans are involved.
- justinjlynn 10y ago
  And yet the server sends you the code to hash your password. Either way, if the server compromised, all bets are off. That said, there are architectures where this may make a difference, but they certainly aren't the usual case.
  - hvidgaard 10y ago
    The difference is that I can verify the code, and the data send. If I send the password to serverside hashing, I can only trust the server to handle it correctly. Security wise that is a fairly important difference.
    - temprature 10y ago
      Are you saying you not only know of some website that does password hashing client-side but that you also inspect the javascript that site serves you every time you login?
      - hvidgaard 10y ago
        Security wise there is a difference. This difference don't matter to the average person. I don't reuse passwords, so I don't need this protection.
- Freak_NL 10y ago
  As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password for everything. > If the server hashes the password, that is effectively the same as storing the password in cleartext. The server hashes passwords to prevent a database leak or bad actor from effectively compromising all accounts at once. It is also a service to the users who — despite being advised not to do so — reuse the same password everywhere. With a proper hashing method (e.g., bcrypt, PBKDF2) these hashes are effectively one-way.
  - hvidgaard 10y ago
    As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password for everything. Agreed, but that does not change the fact that you shouldn't be sending the password to the server, since that is thrusting that the server handles it correctly. If you gurantee that passwords will never be reused, the password is as good a secret as the hash. But if you cannot gurantee this, and that includes nearly all real world systems with humans users, it makes an important difference security wise.
    - Freak_NL 10y ago
      If you are not reusing passwords, you should (from a security standpoint) not care at all. Without client-side hashing the server gets a bunch of characters that are exclusively used for that service, and with hashing it gets another bunch of characters. The only situation where client-side hashing could matter is if you are reusing passwords; but the user can trivially mitigate that by not reusing passwords in the first place. From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. In fact, it can decrease security. By following the NIST guidelines, most up-front password rules are relaxed. However, to guarantee password strength, NIST recommends to do a check against common password lists and dictionaries to guarantee a certain level of entropy. So even if you meet the minimum length check, a password like 'password1980' should fail (common password plus a year). This check cannot easily be done client-side, because from a security standpoint the client is untrusted (especially so with HTTP and HTML/CSS/JavaScript) and it would require a substantial amount of data to be sent to the client (password databases, word lists, etc.). Even without these additional checks, the server still needs to know if your password meets the minimum length requirement. It can only do this reliably by inspecting the password (again, assuming a web browser is the client). So when you enter a new password, the server should check if the minimum length and optionally the minimum entropy are met. At that point the server already 'knows' your password, so client-side hashing whenever you login normally is redundant.
- ykler 10y ago
  (Note: edited to make it more clear that hashing only on the client is insecure.) I think it is true that hashing on the client in addition to on the server offers a little security boost since if someone is able to snoop a login, they will only see a hashed password, which they can use to compromise the user's account on the site being accessed but not on other sites where the user may use the same password (assuming you use a salted hash). Server hashing guards against the case where someone steals the database but not against the case where they snoop logins (and hashing only on the client wouldn't guard against this). Also, it might be practical to use more rounds of bcrypt on the client, but this is hard to say. Maybe you were downvoted, though, because you said server hashing is "effectively the same as storing the password in cleartext." Actually, the main win is probably from hashing on the server; the boost from also doing it on the client seems relatively minor.
  - hvidgaard 10y ago
    If we send the plaintext password we don't know that the server handles it responsibly. We don't know if they had to push an update under time constraint means that they now store passwords in plaintext. What we know is that we send plaintext password to the server on every login, that should, in a threat model, be considered as not using hashing at all. On the other hand, if the password is hashed client side, we KNOW that it cannot be stored as plaintext, because the server never knows it.
    - temprature 10y ago
      You're saying no one is doing password hashing right, from Google to Facebook to Apple to Microsoft to this very website we're posting on.
      - hvidgaard 10y ago
        I'm not saying they're not doing it right... I'm saying that in a threat model there is a difference.
    - JetSpiegel 10y ago
- pricechild 10y ago
  What's the difference between this plain "hash" you're sending and a plain "password", other than intentions?
  - tripzilch 10y ago
    Obviously you hash it with a nonce or challenge.

hvidgaard 10y ago

If I hash client side the server will never know my password. If the server hashes the password, that is effectively the same as storing the password in cleartext. /edit: Security wise sending the password, means you trust the server to handle the password correctly. For all we know it stores the plaintext password. If we send the hash, we KNOW that it does not store the password. It's an important distinction to make in real world systems. No matter how much best practices dictates to not reuse passwords, it happens as long as humans are involved.

justinjlynn 10y ago
And yet the server sends you the code to hash your password. Either way, if the server compromised, all bets are off. That said, there are architectures where this may make a difference, but they certainly aren't the usual case.
- hvidgaard 10y ago
  The difference is that I can verify the code, and the data send. If I send the password to serverside hashing, I can only trust the server to handle it correctly. Security wise that is a fairly important difference.
  - temprature 10y ago
    Are you saying you not only know of some website that does password hashing client-side but that you also inspect the javascript that site serves you every time you login?
    - hvidgaard 10y ago
      Security wise there is a difference. This difference don't matter to the average person. I don't reuse passwords, so I don't need this protection.
Freak_NL 10y ago
As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password for everything. > If the server hashes the password, that is effectively the same as storing the password in cleartext. The server hashes passwords to prevent a database leak or bad actor from effectively compromising all accounts at once. It is also a service to the users who — despite being advised not to do so — reuse the same password everywhere. With a proper hashing method (e.g., bcrypt, PBKDF2) these hashes are effectively one-way.
- hvidgaard 10y ago
  As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password for everything. Agreed, but that does not change the fact that you shouldn't be sending the password to the server, since that is thrusting that the server handles it correctly. If you gurantee that passwords will never be reused, the password is as good a secret as the hash. But if you cannot gurantee this, and that includes nearly all real world systems with humans users, it makes an important difference security wise.
  - Freak_NL 10y ago
    If you are not reusing passwords, you should (from a security standpoint) not care at all. Without client-side hashing the server gets a bunch of characters that are exclusively used for that service, and with hashing it gets another bunch of characters. The only situation where client-side hashing could matter is if you are reusing passwords; but the user can trivially mitigate that by not reusing passwords in the first place. From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. In fact, it can decrease security. By following the NIST guidelines, most up-front password rules are relaxed. However, to guarantee password strength, NIST recommends to do a check against common password lists and dictionaries to guarantee a certain level of entropy. So even if you meet the minimum length check, a password like 'password1980' should fail (common password plus a year). This check cannot easily be done client-side, because from a security standpoint the client is untrusted (especially so with HTTP and HTML/CSS/JavaScript) and it would require a substantial amount of data to be sent to the client (password databases, word lists, etc.). Even without these additional checks, the server still needs to know if your password meets the minimum length requirement. It can only do this reliably by inspecting the password (again, assuming a web browser is the client). So when you enter a new password, the server should check if the minimum length and optionally the minimum entropy are met. At that point the server already 'knows' your password, so client-side hashing whenever you login normally is redundant.
ykler 10y ago
(Note: edited to make it more clear that hashing only on the client is insecure.) I think it is true that hashing on the client in addition to on the server offers a little security boost since if someone is able to snoop a login, they will only see a hashed password, which they can use to compromise the user's account on the site being accessed but not on other sites where the user may use the same password (assuming you use a salted hash). Server hashing guards against the case where someone steals the database but not against the case where they snoop logins (and hashing only on the client wouldn't guard against this). Also, it might be practical to use more rounds of bcrypt on the client, but this is hard to say. Maybe you were downvoted, though, because you said server hashing is "effectively the same as storing the password in cleartext." Actually, the main win is probably from hashing on the server; the boost from also doing it on the client seems relatively minor.
- hvidgaard 10y ago
  If we send the plaintext password we don't know that the server handles it responsibly. We don't know if they had to push an update under time constraint means that they now store passwords in plaintext. What we know is that we send plaintext password to the server on every login, that should, in a threat model, be considered as not using hashing at all. On the other hand, if the password is hashed client side, we KNOW that it cannot be stored as plaintext, because the server never knows it.
  - temprature 10y ago
    You're saying no one is doing password hashing right, from Google to Facebook to Apple to Microsoft to this very website we're posting on.
    - hvidgaard 10y ago
      I'm not saying they're not doing it right... I'm saying that in a threat model there is a difference.
  - JetSpiegel 10y ago
pricechild 10y ago
What's the difference between this plain "hash" you're sending and a plain "password", other than intentions?
- tripzilch 10y ago
  Obviously you hash it with a nonce or challenge.