But I might not remember them and the password I used for an especially stringent site. Why not just remind them of the requirements if someone got their password wrong on the first try?
I'd like you to create a login page where a user can log in using their email address and a password.
We want our users to be made to feel as if we take security seriously, so let's use the following secure password requirements that I picked up from a blog post:
* Password must be AT LEAST 6 characters (but no more than 12, because who's going to remember more than 12 characters?)
* There must be at least one number.
* There most be at least one uppercase and at least one lowercase letter.
* There should be at least one special character, but not just any special character, because we don't want things to get crazy. Only these five: &$+#%
Okay, can you code that up for me?
Wait, it'll take how long?
Well, yes, I understand that you not only need to build in the validation logic but also need to build little error messages to let the user know what they've done wrong if their password doesn't meet all the requirements, plus allow time for writing tests, getting UX's rubberstamp, etc.
But I kind of need this by tomorrow afternoon. Is there anything we can consider out of scope?
I hate any requirements for passwords but why go for cornercase email?
If the PM specifies a requirement to filter out email addresses with a single character before the @ sign, then that's a different thing. Maybe there is a business requirement to filter out people who own a domain and give themselves a single character email address? In that case it should be explicitly written into the validation logic and not done as a side effect of sloppy coding.
https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi...
"Traditionally, organisations impose rules on the length and complexity of passwords. However, people then tend to use predictable strategies to generate passwords, so the security benefit is marginal while the user burden is high."
Edit: Adding NIST guidelines too, which say the same https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo...
If that's not the case in general, a good benchmark would be 'can hashcat break this given a reasonable mutation pattern'. The zxcvbn project pretty much provides that.
I've lost count of all the sites where I sign up and paste a long, secure password generated by my password manager. One of three things happens then.
1) The site admins are competent and my strong password is accepted.
2) The site admins are incompetent, and limit password length to a short string, possibly with certain special characters required.
3) The site admins are incompetent and should immediately be fired, because the form accepts my long, strong password, silently truncates it to a shorter length and saves that, and my correctly typed password no longer works. I've discovered this pattern repeatedly after comparing the 'forgot password' email then send with the truncated password in clear text (which is another reason they should be fired immediately) and noticing it is much shorter.
First-world problems, I know, but this annoys me and I would like to see it fixed.
I estimate I've helped 300+ people set up iPads and iPhones, and almost all end up setting up iCloud. There are various steps to set up a new iCloud account, including security questions from a drop-down list and setting a suitably secure password.
This happened 95%+ of the time:
* iCloud prompts for (first time setup) password
* I look away, they type in a password and tap OK/Next
* I look back, iCloud responds that the password is not strong/secure enough
* I explain that Apple passwords needs to be of a certain strength, and include 1 or more capital letters, and 1 or more numbers.
* The client tries again: makes the first character (a letter) capital and tacks a `1` on the end.
Is it an intuitive, clean design? Not sure. Definitely didn't guess that the light bulb meant, "show password requirements", but at least it's an attempt.
End of rant. The best password pages are those who just warn you for things like min. length (a 2 character password is definitely a bad idea).
It's hard to answer a question phrased this way because there can be any number of reasons why a useful feature is not implemented. Time constraints, budget constraints, process constraints, organizational constraints ... and then somewhere in this long list is, "Gee, we just never thought about it."
Perhaps a more interesting question is:
Among those of you who believe that providing password requirements up-front is a useful feature, did you implement that feature in past projects? If not, what prevented you from doing so?
A better answer to the problem is to not have password requirements because it's the user's responsibility to choose a secure password. If their password is compromised because it was their dog's name or "password1234" then it's their fault.
A way to engineer against brute-force hacking is to limit the number of attempted logins per username and IP. If they hit the limit then their account should be locked or their password should be automatically be reset with an email.
While I agree with you on some level, this is quite contrary to the spirit of our times. Plenty of otherwise smart people have pretty dumb passwords. I'm similarly ignorant of enough things that I don't judge them as simply deserving what they get.
1: if your site is uncluttered -- that is, it hides non-essential information -- it will be more appealing to the user;
2: if your site is following practices common to other sites, the average user will have already learned those practices before coming to your site;
3: if a specific user demonstrates a need for guidance/non-essential information, that information should be made explicitly available.
Applied to password requirements:
- Show the password field without requirements (uncluttered initial state)
- If they enter a valid password, all is well (happy path)
- If they enter an invalid password, surface the requirements (explicit guidance)
If your primary email account is hacked, you're pwned in all kinds of ways that a password won't help, e.g. "forgot my password" requests. And if you don't care about others using some junk website that requires logins, you can give them a throwaway Mailinator account.
At the end of the day, making life easier for users is not a priority unless it affects the bottom line.
The OP is talking about the login dialog.
I think everyone can agree that hidden requirements are the worst. Some sites do this out of a misguided notion that it gives the hackers information so it must be hidden for security.
IMHO, the only requirement that really does anything is length. In my experience it's easier to type a 16 character passphrase than some jumbled up mess that's easy for a computer to guess anyway.
Good password (fails many security requirements): "Cokar fed Hunganix!"
Bad password (will usually be accepted): "+yP3wr1t3R"
I strongly disagree with this. Using a password store guarantees that it is technically possible for someone to recover a complete list of my passwords without me being aware. And means I am either storing my passwords online someone which makes it far easier for that technical breach to happen, or I am relying on a piece of hardware not failing to maintain access to my account.
Remembering a unique password for each site (that I actually care about, I can write down passwords for sites that I don't) is simply more secure. Sure the passwords will be easier to reverse if you get a hash of them then a real random string, but it would still be extremely difficult/beyond most cracking software (it's easy to increase reversing difficulty by using a long hard-to-reverse suffix shared between all your passwords), and you'd have to steal and reverse a lot of hashes to find useful patterns.
The only scheme I can think of that would be strong would be one that is tool-assisted and given a set of password requirements (length, allowed characters, etc.), a domain, a master key, and an incremental counter, derived keys and formed passwords on the spot, but I'd still need to remember the criteria for each site, and the counter positions, and keep those secured... so whats a few more bytes?
Stable URLs for log in/out, regex pattern (or some such) to spec password reqs, list stock status response codes (eg success, bad email, nym already taken).
New users are thrown into the internet and they find out they have to use an email, and are usually turned towards Gmail, and then they have to use a password. They probably already had a password on their laptops or phones, which are harder to break into because they need physical access to crack, but the new user doesn't know that people can and might remotely try to gain access to their online email service. So they use the same password they had on their laptops. Then they have to sign up for a ton of other services, so they need passwords for them as well. The easiest thing to do is to reuse your password, or slightly modify it.
If people don't know why it's bad to reuse passwords, they won't even think about getting a password manager. Yes, it is very simple and user-friendly nowadays, but it's seemingly a lot of work to change all your past passwords, and to some people it might be even scarier to hide all your passwords to all your accounts behind a single password.
I'm not very familiar with middle and high school curriculums nowadays, but I feel like security is a topic that must be included. A crazy amount of people use the internet and build their whole online personas or store a lot of their personal and important information in a very wrong and insecure way, just because there's nothing to stop them, and that's the easy way.
> If people don't know why it's bad to reuse passwords, they won't even think about getting a password manager. Yes, it is very simple and user-friendly nowadays, but it's seemingly a lot of work to change all your past passwords, and to some people it might be even scarier to hide all your passwords to all your accounts behind a single password.
Maybe we should all make an effort then. Give them instructions on why and how to use a password manager. Before they create an account. It just a high level idea, not very well thought out.
Best just to avoid goofy requirements.