3 ms·

I think you misread me, or I didn't communicate clearly. By "lengthy" I was referring to the policy, not password length. Indeed max password length itself is a

by xoa 5y ago

I think you misread me, or I didn't communicate clearly. By "lengthy" I was referring to the policy, not password length. Indeed max password length itself is another common bit of foolishness, for sanity reasons arguably it shouldn't be infinite but ~150 characters should be fine so that if people want to have a long diceware passphrase that's fine. To the extent passwords are used at all it should be exclusively as input to a KDF or adaptive-hash anyway so storage-side it should all be normalized regardless of input length.

mrtranscendence 5y ago
Ah, gotcha, sorry. "Lengthy (password policies)", not "(lengthy password) policies". I wouldn't call the policies themselves particularly lengthy, though we do have multiple systems with different policies for which we're supposed to use the same password, so there's that -- it's possible to set a password in one place that can't be set in the other. (Would something bad happen if they weren't in sync? I can't see how, other than it wouldn't be clear half the time which password to use.)
- xoa 5y ago
  Sorry for not being clearer. Really though, the only "password policy" should be "no password reuse/dictionary" (check it against haveibeenpwned.com or the like, there is a nice API), and some minimum decent length. Preferably with a decent user friendly generator option for default suggestions too, and password manager friendly. It's probably not the weakest link at that point. "Multiple systems with different policies for which we're supposed to use the same password" seems like it should just be SSO? But I recognize in reality when using archaic systems at businesses with no budget sometimes hacks are just the best that can be done, and that's how it is. I mean, obviously best of all is no shared password, use proper key via hardware token instead and the password/PIN or (gasp :)) biometrics is purely something the user uses to activate the token. Unfortunately it'll probably be awhile until we get there. But the general use of baroque password policies, particular when interfacing with the general public, is still an anti-feature for security which has finally started to fade away.

by xoa 5y ago

mrtranscendence 5y ago

Ah, gotcha, sorry. "Lengthy (password policies)", not "(lengthy password) policies". I wouldn't call the policies themselves particularly lengthy, though we do have multiple systems with different policies for which we're supposed to use the same password, so there's that -- it's possible to set a password in one place that can't be set in the other. (Would something bad happen if they weren't in sync? I can't see how, other than it wouldn't be clear half the time which password to use.)

xoa 5y ago
Sorry for not being clearer. Really though, the only "password policy" should be "no password reuse/dictionary" (check it against haveibeenpwned.com or the like, there is a nice API), and some minimum decent length. Preferably with a decent user friendly generator option for default suggestions too, and password manager friendly. It's probably not the weakest link at that point. "Multiple systems with different policies for which we're supposed to use the same password" seems like it should just be SSO? But I recognize in reality when using archaic systems at businesses with no budget sometimes hacks are just the best that can be done, and that's how it is. I mean, obviously best of all is no shared password, use proper key via hardware token instead and the password/PIN or (gasp :)) biometrics is purely something the user uses to activate the token. Unfortunately it'll probably be awhile until we get there. But the general use of baroque password policies, particular when interfacing with the general public, is still an anti-feature for security which has finally started to fade away.