4 ms·

Or, you could just do what NIST recommends and not impose arbitrary password requirements beyond being 8+ characters and and not appearing in a list of known pa

Or, you could just do what NIST recommends and not impose arbitrary password requirements beyond being 8+ characters and and not appearing in a list of known passwords. https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=no%20other%20complexity%20requirements%20for%20memorized%20secrets%20should%20be%20imposed https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=no%20....

kinggencha 4y ago
I know I COULD, but my PO is telling me that they saw this on a really popular website and that we should really be doing it that way because the big guys obviously know what's right.
Shank 4y ago
I really like the compromise of using zxcvbn to calculate entropy and offer suggestions on how to make stronger passwords as a good compromise. It won't be tripped by password managers generating passwords, and it'll be usable enough for real humans that they won't mind dealing with it.
- samastur 4y ago
  We use zxcvbn and allowing only good passwords (score >2) is already too hard for many people to figure out a usable password.
  - atoav 4y ago
    Did you consider adding password suggestions? I do this. Generate 10 passwords and make them clickable.
    - hdjjhhvvhga 4y ago
      This is the only thing that makes sense. Asking the user to create a password that is complex enough is just a waste of their time.
      - atoav 4y ago
        I would not go so far and say this is the only thing that makes sense. It made sense for my service, because it runs in a context where people can trust me to not copy the password suggestion and store the clear text. But every application context is different, so maybe offering a clear text password for your users to choose might ring the wrong bell in yours.
  - Tostino 4y ago
    This is too real. I wrote a java port of it to use with my SaaS, Nbvcxz. I had attended many in-person and webinar training sessions with our customers, and inevitability you'd have someone who was just unable to get past creating a password that didn't contain their name and birthday, or part of their email address, or the company name...all of which are added to a personalized exclusion dictionary. These are all internal users at large CPG companies in sales or accounting. I don't understand how so many people who have to work with software all day cannot figure out passwords and login flows.
jhgg 4y ago
This is what we do at my place of work. Minimum 8 characters - and the password cannot appear as one of the top compromised passwords in HIBP list. Except in France - CNIL does not agree with NIST. :(
- seszett 4y ago
  I'm not sure exactly in what they don't agree with NIST in your mind but CNIL recommends minimal entropy rather than minimum length (without "special characters, numbers, etc" restrictions), also recommends checking against a blacklist and above all that recommend using other methods than password authentication when possible. That doesn't strike me as incompatible with NIST recommendations.

kinggencha 4y ago

I know I COULD, but my PO is telling me that they saw this on a really popular website and that we should really be doing it that way because the big guys obviously know what's right.

Shank 4y ago

I really like the compromise of using zxcvbn to calculate entropy and offer suggestions on how to make stronger passwords as a good compromise. It won't be tripped by password managers generating passwords, and it'll be usable enough for real humans that they won't mind dealing with it.

samastur 4y ago
We use zxcvbn and allowing only good passwords (score >2) is already too hard for many people to figure out a usable password.
- atoav 4y ago
  Did you consider adding password suggestions? I do this. Generate 10 passwords and make them clickable.
  - hdjjhhvvhga 4y ago
    This is the only thing that makes sense. Asking the user to create a password that is complex enough is just a waste of their time.
    - atoav 4y ago
      I would not go so far and say this is the only thing that makes sense. It made sense for my service, because it runs in a context where people can trust me to not copy the password suggestion and store the clear text. But every application context is different, so maybe offering a clear text password for your users to choose might ring the wrong bell in yours.
- Tostino 4y ago
  This is too real. I wrote a java port of it to use with my SaaS, Nbvcxz. I had attended many in-person and webinar training sessions with our customers, and inevitability you'd have someone who was just unable to get past creating a password that didn't contain their name and birthday, or part of their email address, or the company name...all of which are added to a personalized exclusion dictionary. These are all internal users at large CPG companies in sales or accounting. I don't understand how so many people who have to work with software all day cannot figure out passwords and login flows.

jhgg 4y ago

This is what we do at my place of work. Minimum 8 characters - and the password cannot appear as one of the top compromised passwords in HIBP list. Except in France - CNIL does not agree with NIST. :(

seszett 4y ago
I'm not sure exactly in what they don't agree with NIST in your mind but CNIL recommends minimal entropy rather than minimum length (without "special characters, numbers, etc" restrictions), also recommends checking against a blacklist and above all that recommend using other methods than password authentication when possible. That doesn't strike me as incompatible with NIST recommendations.