Thats freakin awesome
Looks good Jeff.
Some other things I think might be mentioning.
SSL the whole page, not just the login form/frame. That seems to be a common mistake among these new SPAs and ajaxy sites.
Edit: Just noticed⌠uhh Jeff we need to talkâŚ
Lockout notification emails are an empowering way to protect your users from robot ninja attacks. If you suspect robots are trying to login, making them wait is meh~ You have the userâs email address. Donât you think that, if you suspect that something fishy may be going on, its worthwhile to alert the user?
It does no harm to lock an account if unlocking it is easy and youâre proactive about it. I make 3 (which is unnecessarily low, so lets say 5) 5 failed attempts, go ahead and lock it, tell me youâve locked it, and that an SMS/email token is inbound. And I can use that token to immediately unlock the account, and the login form has automatically presented that workflow, no clicks necessary.
But donât assume it was me that tried to login, it could have been a cyborg pirate, so along with the token in the SMS/email, explain what has happened.
"If this wasnât you trying to log in, reply âNOT MEâ to secure your account."
SMS is the most effective way of alerting the user in a timely manner. People check their texts waaaaaay more than they check their email.
So if you wanted to be very brief: âdiscourse.site.com security notification - too many login attempts. Check email for details. Unlock token: 5K9X3â
Also thank you for testing password fields, so many sites that donât make it a pain to use lastpass.
I was with you until you said to tell the user that their e-mail address doesnât exist. When you do that, it generates an undesirable side effect which you never address:
I can now enumerate your user database with ease, and in the process I have an email I can use to contact (read Phish) that user
This is the reason that so many security standards actually prohibit this behavior; we used to do it all the time, and it made the lives of attackers much easier.
The better solution is to provide a method for people to recover their username if they suspect theyâve forgotten. One good way is to email them a âhey, you donât have an account hereâ message using the incorrect email they supplied (only do this once per day, please). This provides nothing to an attacker, but:
- helps a user who may have forgotten which email they used (you can provide help text in the error to prompt them to check their email)
- tips off a user that someone might be trying to attack their account using a related breach/etc.
Yea, I actually planned on making a chrome extension for that, but its a bit too hardâŚ
I have the same problem, Iâm using my basic password and adding numbers or symbols based on the sits requirements, so many times Iâm resetting my password just cuz I forgot the password requirements on this site, if it would be a small tooltip with a message âhey, password requirements are âŚâ It would be much easier to recall my passwordâŚ
I think this should definitely be something to consider when creating a log in form.
The âdonât forget the keyboardâ topic made me laugh, I have a client that works with DreamHost, and I get frustrated every time I log in to his DHâs panel, user TAB pass TAB enter takes you to Remember your account, sigh. Good article and thanks for the Randyâs video, inspirational.
Al
I can now enumerate your user database with ease, and in the process I have an email I can use to contact (read Phish) that user
A delay between allowed password reset requests (say, 1s per IP) should remediate this. (And if you are enumerating against a number of known emails, what prevents you from phishing them anyways).
Otherwise, you are forcing the users to check all their email accounts before they can find out which one they used, consider how much trouble it is on a mobile device.
Iâm not sure if the double-password box for confirmation is necessary or preferable anymore. I use a bigass password so I guess itâs possible Iâll make a typo, but then I can just reset my password if I canât log in. Itâs inconvenient to occasionally have to do that, but itâs always inconvenient to have to enter my password twice when I sign up. Have you ever just copied and pasted in a verification field for email or password just because you didnât care (email is a bad example because it would screw up where reset information is sent)?
The only issue I think you missed is the dreaded âCOPPAâ law in the United States. It is a horror for sites that exist for children under the age of 13 when it comes to collecting identifying information for authentication. According to the updated regulations, as of July 1, 2013, you are not allowed to capture email addresses, IP addresses, nor any demographic (age, race, address, phone, etc.) data about children 12 years old or younger.
My company runs multiple web sites for games targeted at children ages 8+. So our login systems needed to be both simple, and comply with the COPPA regulations. Hence, we cannot collect an email address until the user makes a purchase with a credit card (COPPA literally specifies this as one of 5 ways we can verify that a child has the consent of their parents to access our site). This may be why some sites do not allow an email address for logins (it is for us).
BTW, the result of this law for our site is - if you forget your password (and you are under 13), you are essentially screwed unless youâve made a credit card purchase that we can trace back to you.
Iâd love to hear suggestions from anyone else on how to compensate for the limitations imposed by the regulations.
This behaviour has been in fact proposed as the basis for a no-password authentication alternative.
So, not âEl Duderinoâ, then. Got it.
What if people type it in wrong⌠twice?
Except that banks are more likely to have strict rules about what can be in a password. So if you have a bad password on MyChatSite.example.com (e.g. âpasswordâ) and that get hacked, itâs not useful for hacking into other sites. Whereas if you are forced to use a good password on MyChatSite.example.com, it is more likely to be your password at a bank website.
That said, itâs bad form to allow any password, since it trains users to try using a weak password.
On the third hand (as it were), password security is broken already. As another person commented, even if youâre using bcrypt or scrypt, if the password file gets stolen, an attacker will be able to guess a userâs password soon enough, since users arenât good at coming up with good passwords. We really need to move away from passwords and toward a different security model.
This post inspired me to finally release the code for my How Secure is My Password? site so that people can use it on their own sites. Thanks!
OK, so now my botnet (everybodyâs got one of those, right?) can enumerate your database with ease. I donât think anybody is saying itâs a one-sided discussion, and never OK, but itâs definitely a trade-off between security and convenience.
Awesome! But can anyone show me the coding of it or How to create it perfectly? I want to create it for my blog: Android Rooting
Great article. Two additions, if I may:
- if I failed to login with email+pass, when I hit âforgot passwordâ remember the last email I typed.
- Remember which sign in method I used on this device. Donât even hint the username if you want to respect my privacy, but I believe noting that âTwitter & GitHub were used to access this site from this deviceâ is very useful.
Why is there a separate screen for login and sigh up? Surely what you mean is âhey! I have never had those credentials before, did you mistype em, or do you want to sign up?â
Why is it asking men for an account name and email if I press the âgoogleâ button? I just told you who I am by pressing that button in the first place. Give me a user name thatâs some hash of my credentials and never show it to me. My visible id for all purposes should be âgoogle-icon PaulMurrayCbrâ.
You say âRegisterâ and âSign Inâ are the best terms, but your subconscious doesnât agree with you.
In you post âRegisterâ occurs 1 time, âSign upâ occurs 4 times, âSign Inâ occurs 5 times, âLog inâ occurs 13 times and âLoginâ occurs 29 times including in the title itself.
Very interesting post and also very interesting discussion, thanks.
Weâve done a lot of observation of low skills/low confidence users recently, so here are some extra thoughts based on their experiences.
Some people do not have email addresses or do not have access to their email.
Some low skills/low confidence users do not see any relevance to them of email, or feel unable to use it even if they had it. They may have limited access to computers - for example, using a friend or family memberâs computer when they do have access, or only using a computer in a library or some other public arena. They may have an email address in theory but not recall it, or they may not have an email address.
A signin process that requires email excludes these users. That may be fine for many sites, but it isnât acceptable for others - such as a government service where there is no alternative.
Some people have shared email addresses.
Another characteristic of low skills/low confidence users is that they may live in households where lack of money or lack of confidence means that they only have a single computer, and lack the skills to set up email accounts for each member of the household. The people in the household share an email account, and manage their email correspondence as a joint activity.
A signing process that requires a unique email address for each user excludes the second and subsequent user in these circumstances.
Label the buttons with what they do
Youâve placed the two options (âsign upâ / âsign inâ) as two buttons close together in most of the suggested layouts. Weâve seen this work well as users see the two options and consider them as a pair.
Weâve also seen low skills/low confidence users get stuck as they donât understand the term âsign inâ. In one test, users correctly chose the other button (which had a site-specific name) solely because they didnât understand âsign inâ so opted for the other button as the least-worst available choice. When a user has low confidence to start with, any âleast worstâ choice like this that further undermines confidence is a definite risk for breaking off.
So: having a pair of buttons to consider together: excellent. But careful choice of the text on the buttons is essential - and of course, testing that choice with your specific users.
Frequency of use of a term is not the same as it being understood in context
I agree with your analysis that âsign inâ is used more frequently than âlog inâ.
Any high skills/high confidence user is very likely to know âsign inâ, âlog inâ and âloginâ and what their effects are. If thatâs your audience, it wonât matter much which you use.
But, as mentioned above, that doesnât mean that low skills/low confidence users will understand what you mean by it when they encounter it. So whichever one you choose, you may need to explain it.
Avoid two-column layouts
I donât think itâs yet been mentioned in the column or discussion but itâs worth repeating: donât use two-column layouts. I suspect you didnât bother to mention the issue because you know theyâre troublesome and wouldnât use them.
Similarly:
Donât put textbox labels inside the boxes
Another point thatâs worth mentioning explicitly: labels inside boxes are a disaster for low skills/low confidence users and for accessibility - and theyâre not great for many other users. I suspect this one is also so obvious as an issue that you thought it wasnât worth mentioning, but I see violations of this basic rule so often on sign-in forms that I think it needs to be stated explicitly.
Thanks again for a great article and great comments.
Caroline Jarrett
@cjforms
And why not have only one form with email and pass, that automatically create the user account if that doesnt exist?
I may be missing something obvious, but I couldnt find a reason against it.