Open jasonmunro opened 8 years ago
Good idea.
I must though disagree on several points from the proposal (yes, even NIST has it wrong :(). E.g. min caps 1
min puncuation 1
min symbols 1
are not useful (why is it so is explained under the linked sources on the zxcvbn gihub page I'm referring to below - e.g. remembering and writing symbols and lowercase/UPPERCASE is harder then having the password by 1 or 2 characters longer to achieve way higher security, because people then don't write down their passwords on papers glued to their LCDs, but rather remember them).
For a good strength estimator please see https://github.com/aybabtme/zxcvbn and the literature and explanations linked from that page.
The rest of the proposal (including expiration) is a decent one, thanks!
Thanks for the feedback. It's all about entropy here. Unencumbered by facts, I'm not surprised having a larger overall minimum might outweigh forcing a larger character set. Honestly I like the pass-phrase approach the best. Max entropy, and a phrase that doesn't require a post-it :) Regardless, I plan on making each of these a knob a site can tune to whatever they want.
Regardless, I plan on making each of these a knob a site can tune to whatever they want.
If it's not much more work, then it's undoubtedly the best solution.
@Danelif please advise.
If we do this, we should re-use an existing lib.
We might consider using the PasswordPolicy library. This library allows to define password policies (e.g. minimum length, required character types) and then hash and verify passwords against those policies. More information on this library https://github.com/web-token/jwt-password-policy
https://github.com/web-token/jwt-password-policy gives me "page not found"
Last commit 8 years ago
Some random thoughts of features worth supporting. This module set will only apply for sites using the built in user authentication and not pass-through to a mail service.