4 ms·

I've sent feedback to a couple dozen sites over this. Most were government website (internal military sites are the worst) but when various financial institutio

I've sent feedback to a couple dozen sites over this. Most were government website (internal military sites are the worst) but when various financial institutions started updating their policies they forcing this silliness. When they don't allow spaces in passwords either, I worry.

toomuchtodo 8y ago
Keep in mind, there are situations where the website you're using is interfacing to backend systems that have constraints that can't easily be changed (colloquially known as "legacy systems"). Feedback is good, but change takes time.
- zrm 8y ago
  Passwords should be hashed client-side anyway, so the real issue there is how to encode the password hash in a way that satisfies the legacy system. But this is usually plausible, e.g. by base64 or hex encoding the hash to avoid disallowed characters and then appending specific characters that satisfy the set of required characters.
  - lbotos 8y ago
    Do you know of any systems that actually do this? It's the first I've heard of this technique.
    - zrm 8y ago
      Nothing should be doing this. Insecure legacy systems that wrongfully expect to see the plaintext of the user's password should be replaced with properly functioning ones. But just because they haven't been yet is no excuse to actually give them the plaintext of the user's password.
    - A2017U1 8y ago
      It's a pointless technique as noted by others. Along the same lines though is OPAQUE PAKE, where the server doesn't need to store a password hash, only a salt, making server compromise far less dangerous, it's quite elegant. There's no implementations so far I believe. https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163
  - angelsl 8y ago
    This just makes the password the hash of the user's passphrase.
    - zrm 8y ago
      > This just makes the password the hash of the user's passphrase. There are some other advantages that others have already mentioned, but even if that was all it did it would still be useful in inhibiting an attacker from learning the actual passphrase which many users are likely to have reused on other services.
      - krapp 8y ago
        It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password, which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. Sending a password in plaintext over HTTPS is more secure than hashing it in javascript first and sending the hash.
        zrm 8y ago
        > It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password If it's practical to find a hash collision, your hash algorithm is broken. > which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. The security of a system should not depend at all on that information being secret.
  - mygo 8y ago
    You don’t need to hash a password over the client so long as it’s sent over an encrypted network. The goal of submitting a password is that it’s not sent in open plaintext. Otherwise even if you hash it on the client, the plaintext hash can still be intercepted and used, exactly as-is, as the plaintext password.
    - 0xCMP 8y ago
      You can if you don't want the authenticating side to actually know the plain text. e.g. password + client_salt => hash => send to server => (hash+server_salt)^hash2 => compare to db By doing this you'd protect a user when their password might be accidentally logged (e.g. Twitter recently). Then if you compromise the hash you don't immediately reveal the password itself, just the text needed to authenticate, which can be changed. If you simply change the salt used client side you may not even need to have the user change their password (although obviously better if they did). That said, I don't think this is required, but there is actually a case for it. Also obviously you should never log the password, but mistakes are made. This helps mitigate the risk of that password being exposed.
      - mygo 8y ago
        I agree. So long as the plaintext hashes are hashed again on the sever, then it’s more secure.
- rosser 8y ago
  I'm somehow supposed to care that it's the vendor's tech debt that makes them insecure, instead of regular old bad practices?
- technion 8y ago
  Has anyone got direct, first hand experience with such a thing? I'm wondering if it's become urban legend. I've inherited several ancient code bases where everyone knew silly password rules were a legacy requirement. And ultimately after a lot of digging, every time they were a "legacy limitation" because the original project manager called for it, and could easily be removed by commenting out one check. Which was never allowed to happen, because it was a "constraint that couldn't be changed". I do accept there are databases with eight character fields for maximums, but beyond that, I'm interested in any genuine experience.
twblalock 8y ago
TreasuryDirect is pretty bad about this -- the passwords are not case-sensitive, and they need to be entered using an on-screen keyboard.
- mgkimsal 8y ago
  still? i wrestled with that madness 12 years ago, and had hoped they'd improved it by now. :/

toomuchtodo 8y ago

Keep in mind, there are situations where the website you're using is interfacing to backend systems that have constraints that can't easily be changed (colloquially known as "legacy systems"). Feedback is good, but change takes time.

zrm 8y ago
Passwords should be hashed client-side anyway, so the real issue there is how to encode the password hash in a way that satisfies the legacy system. But this is usually plausible, e.g. by base64 or hex encoding the hash to avoid disallowed characters and then appending specific characters that satisfy the set of required characters.
- lbotos 8y ago
  Do you know of any systems that actually do this? It's the first I've heard of this technique.
  - zrm 8y ago
    Nothing should be doing this. Insecure legacy systems that wrongfully expect to see the plaintext of the user's password should be replaced with properly functioning ones. But just because they haven't been yet is no excuse to actually give them the plaintext of the user's password.
  - A2017U1 8y ago
    It's a pointless technique as noted by others. Along the same lines though is OPAQUE PAKE, where the server doesn't need to store a password hash, only a salt, making server compromise far less dangerous, it's quite elegant. There's no implementations so far I believe. https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163
- angelsl 8y ago
  This just makes the password the hash of the user's passphrase.
  - zrm 8y ago
    > This just makes the password the hash of the user's passphrase. There are some other advantages that others have already mentioned, but even if that was all it did it would still be useful in inhibiting an attacker from learning the actual passphrase which many users are likely to have reused on other services.
    - krapp 8y ago
      It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password, which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. Sending a password in plaintext over HTTPS is more secure than hashing it in javascript first and sending the hash.
      - zrm 8y ago
        > It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password If it's practical to find a hash collision, your hash algorithm is broken. > which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. The security of a system should not depend at all on that information being secret.
- mygo 8y ago
  You don’t need to hash a password over the client so long as it’s sent over an encrypted network. The goal of submitting a password is that it’s not sent in open plaintext. Otherwise even if you hash it on the client, the plaintext hash can still be intercepted and used, exactly as-is, as the plaintext password.
  - 0xCMP 8y ago
    You can if you don't want the authenticating side to actually know the plain text. e.g. password + client_salt => hash => send to server => (hash+server_salt)^hash2 => compare to db By doing this you'd protect a user when their password might be accidentally logged (e.g. Twitter recently). Then if you compromise the hash you don't immediately reveal the password itself, just the text needed to authenticate, which can be changed. If you simply change the salt used client side you may not even need to have the user change their password (although obviously better if they did). That said, I don't think this is required, but there is actually a case for it. Also obviously you should never log the password, but mistakes are made. This helps mitigate the risk of that password being exposed.
    - mygo 8y ago
      I agree. So long as the plaintext hashes are hashed again on the sever, then it’s more secure.
rosser 8y ago
I'm somehow supposed to care that it's the vendor's tech debt that makes them insecure, instead of regular old bad practices?
technion 8y ago
Has anyone got direct, first hand experience with such a thing? I'm wondering if it's become urban legend. I've inherited several ancient code bases where everyone knew silly password rules were a legacy requirement. And ultimately after a lot of digging, every time they were a "legacy limitation" because the original project manager called for it, and could easily be removed by commenting out one check. Which was never allowed to happen, because it was a "constraint that couldn't be changed". I do accept there are databases with eight character fields for maximums, but beyond that, I'm interested in any genuine experience.

twblalock 8y ago

TreasuryDirect is pretty bad about this -- the passwords are not case-sensitive, and they need to be entered using an on-screen keyboard.

mgkimsal 8y ago
still? i wrestled with that madness 12 years ago, and had hoped they'd improved it by now. :/