7 ms·

They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transforma

They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.

adolph 5y ago
I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple. To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.
- dylan604 5y ago
  why would you have to retrieve multiple? could you not calculate the 3 hashes, and then do SELECT WHERE pass = HASH1 OR pass = HASH2 OR pass = HASH3? You don't care which one was correct just that one is.
  - eterm 5y ago
    Please never implement a password feature without reading more about how passwords should be stored.
    - names_are_hard 5y ago
      Instead of just telling the parent that they're doing something can wrong in a condescending way, can you explain what it is they should do differently? At least a link to an article that explains this?
    - dylan604 5y ago
      good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.
      - brigandish 5y ago
        Because the pseudo code looks quite bad? The clause should pick the user not the password or hash or anything like it. The hash (and possibly salt etc) should come back via the selected column list. The other way round is inviting trouble and could indicate a poor understanding, though I agree they shouldn't be so snarky without some explanation.
        adolph 5y ago
        Unless it has been edited since i saw it, the pseudo sql doesn’t select anything, a logical assumption is user identity and not needed. The comparison is between the original hashed password and the hashes made at auth-time. The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. Maybe these generous assumptions about someone’s pseudo code are unwarranted?
        brigandish 5y ago
        > The comparison is between the original hashed password and the hashes made at auth-time. Didn't I write that this shouldn't be done via the clause? I haven't edited my comment either so it should still be there and I see it is. > the pseudo sql doesn’t select anything It should select the hash(es) and bring them back to the app for comparison. > The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. It doesn't matter whether it's a password or a hash, the form of the SQL statement is going to cause trouble and should be the other way round. > Maybe these generous assumptions about someone’s pseudo code are unwarranted? Perhaps you meant to reply to someone else?
        adolph 5y ago
        > It should select the hash(es) and bring them back to the app for comparison. Agreed 100%. Calculating three hashes and sending them to sql for comparison—maybe index lookup—seems backward to me.
  - adolph 5y ago
    You can push the comparison into sql but you still have a series of retrievals and comparisons. Just because it happens in sql doesn’t mean the processes don’t have to happen. In your example you have calculated three hashes, then pushed them to the sql server where the retrieval and comparison occurs.
  - teawrecks 5y ago
    You're now doing up to 3x the work for every login. When servicing millions of requests a second, that cost adds up.
    - lordgrenville 5y ago
      I would imagine it's sequential: check exact match hash, if it fails check uppercase-initial-hash, etc.
    - jsnell 5y ago
      Passwords are only verified on login. Does it seems reasonable that there are millions of logins to Gmail from mobile devices every second? Back of the envelope: 2 million logins per second would mean about 170 billion logins per day. With 7 billion people on the planet, that'd mean about 25 logins per day from each man, woman and child.
    - danachow 5y ago
      “Up to 3x the work” is very misleading, since the average will be much less than 3.
  - ipaddr 5y ago
    By retrieving three you can perform an if on one value; if that fails check the other two values. This allows you to save the other two calls for most logins.
remram 5y ago
You can also normalize the password, e.g. always make the first letter lowercase and reverse the case of the rest if the second letter is uppercase. Then you only have to hash that. HeLLo, heLLo, hEllO, HEllO all normalize to heLLo
- azernik 5y ago
  That only works if they have the same insensitivities across time and platforms. In this case, they still need to preserve the original information, because they're case sensitive on that first transformation for non-mobile devices.
- rovr138 5y ago
  Doing this reduces way more the space of characters and reduces security.
  - freemint 5y ago
    It reduces the password strength by at most two bits. For passwords made solely of non letters there is no reduction in password strength.
    - nitrogen 5y ago
      It's one bit per alphabetic character, isn't it?
      - smrq 5y ago
        No, it's only one bit for the first character and one for the second. The case of every other character is maintained relative to the second character, so the parity there provides the one bit of information for each subsequent alphabetic character.
        nitrogen 5y ago
        Whoops, I didn't notice that the two L's were still capitalized in the normalization example a few comments up.
delaaxe 5y ago
Oh you mean the client sends 3 hashes and backend validates if just one matches?
- cylon13 5y ago
  Hashing is done on the server. Hashing on the client would defeat the whole purpose.
  - phailhaus 5y ago
    Why? If you hash on the server, then you have to send the password in plaintext to the server. EDIT: Oh right, salts.
    - cylon13 5y ago
      More importantly if the server just accepts hashed passwords and stores them, then if you got ahold of a hashed password through a leak you could just use it directly to authenticate by modifying the client. The hashed password just becomes the password with one extra client-side step that you can trivially skip. Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build tables of hashes for common passwords. Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.
      - phailhaus 5y ago
        Great point, thanks!
      - jeltz 5y ago
        If you do not want to send them in plain text you can use SCRAM.
      - juloo 5y ago
        The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example). I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)

adolph 5y ago

I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple. To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.

dylan604 5y ago
why would you have to retrieve multiple? could you not calculate the 3 hashes, and then do SELECT WHERE pass = HASH1 OR pass = HASH2 OR pass = HASH3? You don't care which one was correct just that one is.
- eterm 5y ago
  Please never implement a password feature without reading more about how passwords should be stored.
  - names_are_hard 5y ago
    Instead of just telling the parent that they're doing something can wrong in a condescending way, can you explain what it is they should do differently? At least a link to an article that explains this?
  - dylan604 5y ago
    good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.
    - brigandish 5y ago
      Because the pseudo code looks quite bad? The clause should pick the user not the password or hash or anything like it. The hash (and possibly salt etc) should come back via the selected column list. The other way round is inviting trouble and could indicate a poor understanding, though I agree they shouldn't be so snarky without some explanation.
      - adolph 5y ago
        Unless it has been edited since i saw it, the pseudo sql doesn’t select anything, a logical assumption is user identity and not needed. The comparison is between the original hashed password and the hashes made at auth-time. The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. Maybe these generous assumptions about someone’s pseudo code are unwarranted?
        brigandish 5y ago
        > The comparison is between the original hashed password and the hashes made at auth-time. Didn't I write that this shouldn't be done via the clause? I haven't edited my comment either so it should still be there and I see it is. > the pseudo sql doesn’t select anything It should select the hash(es) and bring them back to the app for comparison. > The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. It doesn't matter whether it's a password or a hash, the form of the SQL statement is going to cause trouble and should be the other way round. > Maybe these generous assumptions about someone’s pseudo code are unwarranted? Perhaps you meant to reply to someone else?
        adolph 5y ago
        > It should select the hash(es) and bring them back to the app for comparison. Agreed 100%. Calculating three hashes and sending them to sql for comparison—maybe index lookup—seems backward to me.
- adolph 5y ago
  You can push the comparison into sql but you still have a series of retrievals and comparisons. Just because it happens in sql doesn’t mean the processes don’t have to happen. In your example you have calculated three hashes, then pushed them to the sql server where the retrieval and comparison occurs.
- teawrecks 5y ago
  You're now doing up to 3x the work for every login. When servicing millions of requests a second, that cost adds up.
  - lordgrenville 5y ago
    I would imagine it's sequential: check exact match hash, if it fails check uppercase-initial-hash, etc.
  - jsnell 5y ago
    Passwords are only verified on login. Does it seems reasonable that there are millions of logins to Gmail from mobile devices every second? Back of the envelope: 2 million logins per second would mean about 170 billion logins per day. With 7 billion people on the planet, that'd mean about 25 logins per day from each man, woman and child.
  - danachow 5y ago
    “Up to 3x the work” is very misleading, since the average will be much less than 3.
- ipaddr 5y ago
  By retrieving three you can perform an if on one value; if that fails check the other two values. This allows you to save the other two calls for most logins.

remram 5y ago

You can also normalize the password, e.g. always make the first letter lowercase and reverse the case of the rest if the second letter is uppercase. Then you only have to hash that. HeLLo, heLLo, hEllO, HEllO all normalize to heLLo

azernik 5y ago
That only works if they have the same insensitivities across time and platforms. In this case, they still need to preserve the original information, because they're case sensitive on that first transformation for non-mobile devices.
rovr138 5y ago
Doing this reduces way more the space of characters and reduces security.
- freemint 5y ago
  It reduces the password strength by at most two bits. For passwords made solely of non letters there is no reduction in password strength.
  - nitrogen 5y ago
    It's one bit per alphabetic character, isn't it?
    - smrq 5y ago
      No, it's only one bit for the first character and one for the second. The case of every other character is maintained relative to the second character, so the parity there provides the one bit of information for each subsequent alphabetic character.
      - nitrogen 5y ago
        Whoops, I didn't notice that the two L's were still capitalized in the normalization example a few comments up.

delaaxe 5y ago

Oh you mean the client sends 3 hashes and backend validates if just one matches?

cylon13 5y ago
Hashing is done on the server. Hashing on the client would defeat the whole purpose.
- phailhaus 5y ago
  Why? If you hash on the server, then you have to send the password in plaintext to the server. EDIT: Oh right, salts.
  - cylon13 5y ago
    More importantly if the server just accepts hashed passwords and stores them, then if you got ahold of a hashed password through a leak you could just use it directly to authenticate by modifying the client. The hashed password just becomes the password with one extra client-side step that you can trivially skip. Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build tables of hashes for common passwords. Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.
    - phailhaus 5y ago
      Great point, thanks!
    - jeltz 5y ago
      If you do not want to send them in plain text you can use SCRAM.
    - juloo 5y ago
      The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example). I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)