5 ms·

> must contain letters in mixed case, must contain numbers and must contain symbols Please don't do this. Have a minimum length, but don't force me to miss it

> must contain letters in mixed case, must contain numbers and must contain symbols Please don't do this. Have a minimum length, but don't force me to miss it up. My password manager shouldn't have to try multiple times to generate matching passphrase.

shiado 8y ago
Yeah this is annoying. Simply consider a^b, what makes that expression grow faster, increasing a, or increasing b? b is better mathematically and for mental overhead.
- zawerf 8y ago
  The mathematical part was not obvious to me, so: The derivative with respect to a is: b(a^(b-1)). The derivative with respect to b is: log(a)(a^b) or (a log(a))(a^(b-1)). So it's better to increase b when alog(a) > b. Which is typically the case where a is 26 for lowercased letters and b is like 10 for password length. This analysis might not be totally correct since the cost of adding one extra allowed character vs increasing password length by one is not the same but w/e.
MithrilTuxedo 8y ago
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.
- 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. :/
sneak 8y ago
> Please don't do this. They didn't, they just chose off the shelf PHP forum software written by idiots that does this and a million other stupid things.
- dchuk 8y ago
  I am they. You are correct. I'll tone it down.
- code_duck 8y ago
  I couldn’t imagine releasing a forum for the hn community that wasn’t also a neat software project. Using phpbb seems like the antithesis of something this community would appreciate, other than perhaps for the practicality of choosing something common.
  - dchuk 8y ago
    That was kinda the point of this whole thing though. This wasn't a software project for me, this was a community project. I have no interest in developing a forum, but I do have interest in participating in one. From what I can tell so far, what we setup seems to be working fine. If we hit a wall, I'll search out the next most practical option.
    - code_duck 8y ago
      That makes sense as administrating a forum takes a significant investment of time, and you don’t necessarily have enough time to run a forum and also develop the software. However, if it became popular, I would expect some of us would want to hack on the software... but who would want to work on a phpbb theme? I’d pretty much rather be using a Google + group.
      - krapp 8y ago
        I've seen enough custom forums appear here only to die out to know that building the software and building a community are two completely different things and that one shouldn't expect that they will come if you build it. I can see the temptation to want to hack around on it because it's a forum for hackers, but it's not as if HN is taking pull requests either.
dchuk 8y ago
I'll adjust! EDIT: Changed this to just have a minimum length restriction. Thanks for the feedback!
- kchr 8y ago
  Good work! Have a cookie.
  - app4soft 8y ago
    NO NEED COOKIES! Please, disable cookies for HackerForums.co too.
shanghaiaway 8y ago
> must contain letters in mixed case, must contain numbers and must contain symbols I mistook this for being about usernames at this hacker forum

shiado 8y ago

Yeah this is annoying. Simply consider a^b, what makes that expression grow faster, increasing a, or increasing b? b is better mathematically and for mental overhead.

zawerf 8y ago
The mathematical part was not obvious to me, so: The derivative with respect to a is: b(a^(b-1)). The derivative with respect to b is: log(a)(a^b) or (a log(a))(a^(b-1)). So it's better to increase b when alog(a) > b. Which is typically the case where a is 26 for lowercased letters and b is like 10 for password length. This analysis might not be totally correct since the cost of adding one extra allowed character vs increasing password length by one is not the same but w/e.

MithrilTuxedo 8y ago

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.
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. :/

sneak 8y ago

> Please don't do this. They didn't, they just chose off the shelf PHP forum software written by idiots that does this and a million other stupid things.

dchuk 8y ago
I am they. You are correct. I'll tone it down.
code_duck 8y ago
I couldn’t imagine releasing a forum for the hn community that wasn’t also a neat software project. Using phpbb seems like the antithesis of something this community would appreciate, other than perhaps for the practicality of choosing something common.
- dchuk 8y ago
  That was kinda the point of this whole thing though. This wasn't a software project for me, this was a community project. I have no interest in developing a forum, but I do have interest in participating in one. From what I can tell so far, what we setup seems to be working fine. If we hit a wall, I'll search out the next most practical option.
  - code_duck 8y ago
    That makes sense as administrating a forum takes a significant investment of time, and you don’t necessarily have enough time to run a forum and also develop the software. However, if it became popular, I would expect some of us would want to hack on the software... but who would want to work on a phpbb theme? I’d pretty much rather be using a Google + group.
    - krapp 8y ago
      I've seen enough custom forums appear here only to die out to know that building the software and building a community are two completely different things and that one shouldn't expect that they will come if you build it. I can see the temptation to want to hack around on it because it's a forum for hackers, but it's not as if HN is taking pull requests either.

dchuk 8y ago

I'll adjust! EDIT: Changed this to just have a minimum length restriction. Thanks for the feedback!

kchr 8y ago
Good work! Have a cookie.
- app4soft 8y ago
  NO NEED COOKIES! Please, disable cookies for HackerForums.co too.

shanghaiaway 8y ago

> must contain letters in mixed case, must contain numbers and must contain symbols I mistook this for being about usernames at this hacker forum