It is easy to understant that having strong passwords is always better. Yet, do strong password requirements lower the conversion rate of products that need registration?
While googling I could not find data supported evidence, although the discussion about this being counterproductive is not new.
It would be great if you share your own experiences.
My name is James and I’m from Barcelona. I’m working on a project. I hope to present it here soon. So far, bootstrapped has helped me on several issues already. I like that bootstrapped is an enjoyable to read solution-oriented community.
The StackExchange link discusses password complexity rules but I don’t think that entirely applies to password length.
As a user I get annoyed when registration forms ask me anything other than having a minimum length. Eg: don’t use spaces, don’t use more than 12 characters, don’t use that character, etc.
Personally, I would find it hard to believe that simple password length would lower registration rates, although it’s my subjective opinion.
When I am forced to use a password that I cannot remember, it will prevent me from coming back sometimes. I try to log in from my phone while I stored the password in the browser (or nowhere) and when I cannot log in, I sometimes give up. Of course this depends on the kind of service a lot, but if you’re a content provider with a freemium offering, you might be missing out on me getting a paid subscription after a few months.
Depends on why you introduce the password requirement. Is it for security? Or to prevent non tech-savvy people from using your services? Lowering conversion rates can be helpful sometimes if you don’t want helpless customers, who will abuse your support.
I’ve recently had to rework my password system, and while trying to fend off various bizarre requirements from clients (corporate/medical markets) I found the NIST Digital Identity Guidelines (specifically, NIST SP 800-63B). These are very reasonable and well researched, and while NIST is not a worldwide standard, it’s at least something to reference, even if you are not in the US.
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
In other words, NIST suggests using a blacklist of commonly used and compromised passwords, but strongly discourages using complexity rules.
I’d like to use this as a chance to highlight aps that limit the length of passwords to a really small number of characters. I’ve run into a few web apps that don’t allow passwords more than 10 characters. All passwords should allow a minimum of the length password managers generate by default (16 or more characters). Preferably, many more.
Yes, that’s completely idiotic. Especially since the password length doesn’t matter: any barely competent software will hash it to a fixed-length hash that will get stored. Whether you transmit and compute the hash of 10 characters or 1024 characters makes no discernible difference whatsoever!
Yes, a 10 char limit is dumb. There’s a ton of cargo-cult behavior in password systems. The NIST reference is a good set of guideline (though they have some backwards advice too – in particular recommending SMS as a viable 2FA source – it’s not).
That being said, this…
Whether you transmit and compute the hash of 10 characters or 1024 characters makes no discernible difference whatsoever!
…is incorrect. It depends on the hashing algorithm you use. So, yes, there should be a password limit. Not 10 chars (again, just dumb), but if you’re using bcrypt as the hashing algorithm, then you should limit passwords to 72 bytes (not characters, but bytes).
See here for the discussion related to bcrypt:
If you’re using another hashing algorithm, research the details.
Also, to expand on your answer earlier (the NIST recommendations), Have I Been Pwned: Pwned Passwords is a good resource for a set of “[… exclusion] list of compromised values […]”. You can host it locally or use the API to access it remotely.
I think password length and complexity is overrated for most logins. Just block the account after 3 failed login attempts for 5 minutes, after 10 for 50 minutes, …
Then you can’t brute force the passwords.
(And make sure you use a good hash to store the pw hash on disk/db)
