HN Explorer

Ask HN: Why don't websites show password requirements at the login screen?

26 points by muzani ↗ HN
Whatever brute force hacker would already know all the password requirements.

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?

65 comments

[ 2.5 ms ] story [ 95.9 ms ] thread
lotyrin
It's visually unclean, and of dubious security use, because nobody should be trying to remember all their passwords, or using a memorable scheme that is adapted based on requirements, just big random string that meets requirements and is managed somehow.
peterhi
Which would be fine if all sites used the same rules. But I often find that I can only find the rules when I break them. Such as "password too long > 16 characters" or "cannot include a space character" (why not?)
jo909
The rules should be, and in my experience often are, explained where you set/change you password. So on the account creation and change password pages.

The OP is talking about the login dialog.

jandrese
I wouldn't say they are "often" displayed at the password change/set prompt. It's more of a "sometimes" in my experience, although if you get it wrong most sites will then tell you the requirements.

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 sort of agree with the OP. If you are at a login box and put in an invalid character into the password field, the box should tell you that in the failure message. That may very well jog someone's memory that the site has retarded password policy and they had to modify the password pattern.
gpm
> nobody should be trying to remember all their passwords, or using a memorable scheme that is adapted based on requirements

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.

lotyrin
My credential management tool has ~300 credentials in it, of which I use roughly 10% frequently, there is no way for me to remember these, without creating a scheme which someone could eventually reverse given enough of my leaked credentials (so far about 15% of services I use have had breaches using weak hashes, and these tend to end up in public). Such a scheme would also have to support password rotation (for services which are breached, or which expire credentials) If I am going to store them somehow, an encrypted blob seems to handily beat pen and paper.

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?

jawns
Hi, I'm your product manager.

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?

bolololo1
pretty easy with Reactive Angular Forms.
rogual
My favourite are the ones where you're not allowed to use “the portion of your email address before the @” in your password. My email address is r@foon.uk. Fun times :D
gear54rus
Didn't you bring this on yourself?

I hate any requirements for passwords but why go for cornercase email?

gnu8
Now you’re blaming the user though. The user isn’t wrong for having a valid email address.
gear54rus
There are degrees of valid. There is RFC valid and then there is 'common sense' valid (there are degrees of common too). Forcing yourself into barely common valid but RFC valid is user's fault.
uranusjr
I fail to see how this email address does not qualify as common sense valid though. Maybe it’s just me being surrounded by tech-saavy people, but I have a bunch of friends using emails like i@domain.com and me@name.com.
gnu8
Valid is a binary condition. Either an address is valid and you will be able to send mail to it, or it is not. That is usually the sole reason for validating an email address. If a bug in the validation logic causes an unusual email address to invalidate then the code is definitely wrong, not the user.

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.

lps41
I don't see this as cornercase. I see this as going for easiest possible email address to type, and easiest possible email address to verbally communicate to someone.
WhoIsSatoshi
sounds more like product manager here - unless roles blend where you're at
darkerside
I think this is a great question and would love to hear a thoughtful, measured, non-snarky response
jawns
I wrote a snarky response above, but here's my non-snarky response:

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?

darkerside
For me, it's a combination of "never thought of it" and the difficult of convincing the organization it's not a security risk (yes, it sounds silly).
rockostrich
The hypothetical of a manager asking for the feature by the next day is pretty accurate. Besides that, it might be a product or design person that thinks the requirements would clash with the current product/design and don't want to go through another iteration.

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.

darkerside
> it's the user's responsibility

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.

romdev
Here's one reason we don't show password requirements on public pages: If a bad guy has to experiment to find the list of available characters and lengths of a password, it's easier to for us good guys to track that behavior. Alternatively, listing the password requirements makes it easier for him to truncate the dictionary for his brute force attacks. If he knows we don't accept ampersands in passwords, he'll remove all passwords with ampersands from his list of 10,000 most common passwords when attacking our site.
darkerside
He can easily find this out by creating a single account
romdev
Most sites require a email address to create an account, leaving a larger footprint for forensics. The sites I work on require much more personal data that is validated against other systems to confirm identity. Out-of-session page requests are scrutinized for patterns that look like a bad guy checking the locks. Granted, many sites will have client side validation for passwords, but that should be considered a user convenience - not a security measure, and doesn't necessarily have to be as strict as the server side validation. New users won't 'accidentally' enter Unicode escape sequences in passwords, but we need to prevent that on the server side validation and show a generic error "your enrollment failed for some reason" so the bad guy doesn't know if it's input validation or personal data validation that failed.
BrinDaxter
In my experience, it boils down to these assumptions:

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)

beokop
Another issue is that most password requirements change over time, without requiring existing passwords to be changed. There’s no way to tell what the requirements were the last time the user changed their password without breaching confidentiality. Having a list of all previous requirement schemes would be a mess.
ukd1
Actually, it's pretty simple - each time you login, check that the password (now cleartext, as supplied by user) is valid AND meets the current requirement. If it's valid and doesn't, push in to a change password flow with the current requirements. If you're extra careful, you can expire older passwords and require an email reset before use.
_pmf_
UX aside, the set of requirements in place when you created your account may be different from the set of requirements that are in place at the time of login.
snowwolf
Because the ONLY requirement should really be > 8 (or more) characters. Any other requirement will generally lead to users creating passwords with predictable patterns.

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...

reustle
But, he's not advocating for more password requirements.
snowwolf
I know. I'm commenting more on the state of the industry where password complexity requirements are still a thing despite expert consensus that they make things worse.
proaralyst
I'd add 'not in the 10,000 most common passwords' to that requirement.
Scirra_Tom
A password not in a common password list should probably be another imo.
Asdfbla
I'm curious how far practical implementations of the NIST guidelines take the advice to preempt dictionary attacks by not letting users choose known bad choices. Of course the advice is perfectly reasonable, but when a user can't choose 'password', they will probably try 'password1' - not really much safer against the usual password cracking software, do you check that too then? But I guess the article mentions that dilemma too. I guess it's again a tradeoff between not annoying the user and annoying the password cracker sufficiently. :)
proaralyst
password1 and reasonable mutations of password are probably present in the top 10000 passwords.

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.

beering
The first website I've noticed that does this is Expensify. See their login page here, specifically the little light bulb by the password field: https://www.expensify.com/signin

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.

Willson50
The requirements could have changed since the user last set their password.
rvanmil
I think it would be confusing, people only expect feedback on their password during registration or when updating it. Also, requirements can change but that won’t invalidate passwords which were chosen with the previous requirements.
jwilk
How does showing the requirements help the user recall the password?
dest
you may adapt a standard password to specific requirements
jawns
I am somewhat ashamed to admit this, but I used to use a password that had a common base but was adapted to each site according to a formula. However, it did not contain any special characters. So you can bet that whenever a site indicated that special characters were necessary, I would just tack on an exclamation point to the end.
iandioch
I used to do the same. I'm sure that's what thousands of others do too :)
tombrossman
Tangential but here's another one: Why don't websites show the requirements at the _signup_ screen?

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.

thallian
Number three happened to me in the EA Origin client. No idea if it is still like that but it was not too long ago and it was quite infuriating trying to find out why my password never worked when I needed to login again.
cannonedhamster
Number 2 and 3 are my most common ones. I've seen bank logins capped at 8 characters. Oh and getting a mortgage... don't even get me started on mortgage company password security.
[dead] vikin9
" (but no more than 12, because who's going to remember more than 12 characters?)" - please don't do this! What if I use a password manager and I insist to have a long password that I don't need to remember? Moreover, some passwords are easier to remember because they are long.
codegeek
I hate websites that enforce their stupid password requirements on me. Most of them are stupid, did I say that already ? Well, you can ONLY use some special characters not any. Even worse, you CANNOT use some special characters. Ok I keep trying. My best one: paste is disabled. So I cannot copy and paste my super strong password from my password manager because apparently the genius who built it thinks that copy/paste is a bad idea. Did I mention that some password pages have a maximum length rule ? really ?

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).

specialist
I want login & signup params in meta, for password vaults to use.

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).

rad_gruchalski
Counter question: why aren't we educating users to use password managers?
teolandon
Who are "we"? What is a good way of educating every service user ever that password reuse can ruin their lives and that human generated passwords are weak? School? Parents?

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.

rad_gruchalski
"We" as the community who gives them a reason to create these accounts. Whatever system that is.

> 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.

petecooper
I used to offer b2c technical support in my local area, I did it for about 5 years. It involved lots of in-person assistance provided to non-technical folks on setting up Apple iCloud-enabled devices where the client was just too spooked or unsure about the process and needed help.

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.

pbreit
Probably tradition & aesthetics.

Best just to avoid goofy requirements.

peterwwillis
The site's devs & testers simply never even see the invalid password screen - only automated scripts with test credentials ever interact with it. They have a completely different experience, and that affects how the site is built.

At the end of the day, making life easier for users is not a priority unless it affects the bottom line.

jlebrech
and don't forget preventing pasting
jlebrech
I worked a place where the password requirement for the system was 3 numbers, 2 letters, 3 numbers. and you had to change it every 3 weeks.
username223
Password rules are dumb, but why do websites even require passwords when they require an email address and offer a "forgot my password" link? The user clicks the link, it sends a one-time login URL to the address, that login URL sets a cookie, and there you go.

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.

commenter1
None of the pages I host have any password requirements. Well, one, you have to have a password. One char is enough. Some might wonder why would you do that, but why would you force people to make complicated passwords if the site in question doesn't have anything worthwhile to steal? Like one of my sites is a tv guide, why would I want to force my users to use +8 character passwords? Pure stupidity.
IshKebab
Because people who are smart enough to think of that aren't stupid enough to have silly password requirements.
pathikrit
Is there a database of leaked passwords somewhere? I would simply enforce that your password is not in the leaks? Probably would capture the most common 100k passwords anyway this way?