Techniques To Simplify Sign-Ups and Log-Ins
smashingmagazine.com
smashingmagazine.com
Am I the only one who thinks that is really unintuitive? I don't even think clicking on that icon would cross my mind as a user, and I would spend my time trying to find the "Forgot Password" link.
I think most places use the "Forgot Password" link now so I think most people come to expect it. I know I would.
Maybe that's unfair; expecting a user to attempt to login even if they're not sure of their details, but it always seemed reasonable enough to me.
So now only users with Javascript enabled can use your website. I'm sure that will increase conversion.
> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can.
Not true anymore.
> you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots
Apparently those of us that are blind, browse from the terminal, or use automated form-fillers are bots and not users too?
Some of this advice is good, some of it is very obvious and widely implemented, and some of it is bad. As the author has left determining which are which as an exercise to the reader, I'm not sure they know either.
It's easy to measure what percentage of your users have JavaScript disabled. For a consumer website, it's probably measured in the hundredths of a percent.
If you can make a change that increases the conversion for 99.97% of your users, even at the cost of ZEROING the conversion for 0.03% of your users, then you will still come out ahead.
Also, it's trivial enough to add a <noscript> tag advising users to turn on Javascript (with a friendly "here's how" link), or you can do the work to degrade gracefully. Your conversion might drop for such users, but there's no reason it should go to zero.
Another site I maintain shows numbers like 3% IE6 and 1% non-JS. What a difference!
Of course, for the first site I mentioned, we made it sure the site graciously degrades for non-JS and/or IE6 users. We don't want to lose 15% of our customers.
I never even consider it anymore.
This system has a few benefits:
* No annoying "username already taken" or "password too short" rejections that make people give up.
* No junk accounts that haven't been verified since I don't create an account until the first login
* Person's email history has a record of their password if they're the type of person that doesn't care to change it.
* Since I'm really lazy, the account creation code is also the password recovery code. It just emails a new password.
I don't see any downsides with my system.
There is nothing stopping an extra security conscious user from deleting the email and changing their password right away. What it does is to give a convenience to users that want to treat your service as a trial. Picking unique user names and password is too far down the developing a relationship path for me personally.
I once made the mistake of emailing a friend of mine the password to an ssh account — roughly 6 months later someone logged in with that password and added a spammy link to one of my HTML pages — my friends machine wasn’t hacked, but likely the (university) server storing his email had.
Also, our online shop email the buyers from a generated non-guessable address (to track replies/bounces). Occasionally these receive spam.
So I don’t trust that what I write in an email is only seen by the person it is sent to, unless the content is encrypted.
And just for the records, I disabled password login and installed fail2ban long ago to avoid new server break-ins :)
The confirmation step via emails is one of those things that has been copied over and over, without knowing, in many cases, what problem it addresses in the first place and if it's crucial to one's particular situations.
I think having to interrupt your visit to log into your email, is another speed bump to a smooth registration process.
A better approach, in my opinion, would be to let users just start interacting with your service right away. Give them 5 to 7 days to confirm their account, after which it is automatically suspended. You can let them know the next time they try to login that they never actually clicked the link they received via email a week earlier. The timeframe is long enough that they can actually use the service with no hassle and it's short enough that they won't have forgotten which email and password they gave during registration.
Of course, if the operations they're trying to perform in your site are sensitive enough (e.g. purchase, sale), you should let them know that it requires an immediate confirmation of the email address.
Other unrelated advices:
- if you use the email as a login name, then allow users to have whatever handle they'd like. i.e. don't make the username unique. Also, allow spaces in that field. e.g. StackExchange.
- under no circumstance should you keep an unencrypted record of the password. It's tempting to think that in the name of user friendliness, whenever someone loses their password, you will just send it back to them. As soon as I see my password sent to me in an email, I usually logon to the website, change the password to 12345 and depending of the sensitivity of the data kept by the service (e.g. web hosting), I would consider stopping using it altogether (Ironically, I've had cases of websites telling me that 12345 as a password isn't secure enough for their service, after they'd sent me my password via email).
On a desktop app, you don't have to enter a filename until you're ready to save...why should you have to do that on the web? (of course, this isn't useful in cases where data is sensitive)
But I agree that new users having to leave the site to check their e-mail is a hurdle to get over.
1. Click login
2. Choose account provider
3. Grant us authorization access
4. Done - we pull your name and email address from the OAuth information and autopopulate your user profile.
At this point we don't strictly need any more information, and adding more account providers doesn't increase the number of steps. Actually, when we only supported Google accounts we didn't have a step #2.
We may start asking people some more questions, but for now signing up and logging in virtually identical user experiences.
Very likely we're going to have to engineer an additional sign-in step for Twitter and LinkedIn that we don't need from Oauth providers that do provide the info:
1) Click login
2) choose twitter or linkedin
3) if the account is new, ask for name and email address
4) send out confirmation email with account activation link
5) user clicks activation link in the email
6) done
The reason for the activation email is that we really really need to confirm the address for our service to work correctly and to protect ourselves from spam. Otherwise we'd just accept what they enter.
For Twitter, we may decide to provide a slightly modified version of our service for scheduled tweets rather than scheduled email, but that'll be a ways off. In that case, if I remember correctly, we should get all of the relevant info from Oauth anyways.
But, at the moment since we support only two providers, and those providers tend to be pretty divisive with little overlap, we haven't noticed any real problems yet.
No idea what the solution to this problem is, but I suspect it isn't going away.
Let the user pick a username to go with the ID provider. When you fill in the username, it'll look up (AJAX) which provider was used and offer/highlight that one?
The question is, is it a security risk if anyone can type in any username to find out which ID provider it is used with?
Personally, I think "don't have a newsletter" is a great idea (it reduces UI cutter too), but people want to send newsletters and the only way to make sending a newsletter worth the time spent to prepare it is by making it opt-out not opt-in.
edit: I'm not saying I support this, just that a newsletter is never done in the users' interest but as an advertizement. It might make for good UX for the user for it to be unchecked, but thats kind of the point, the entire concept of the newsletter relies on bad UX to gain subscribers.
Indeed the Article only says they have to allow you to object, nothing about the company not sending you repeated emails when you do object.
Looks badly drafted and without teeth IMO.
--- http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electr... http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:... - full current text
AFAIK most made opt-out illegal, even if the directive didn't necessarily require it well.
Assuming your newsletter might be something your users would actually want to read (crazy, I know), the newsletter preview link is a fantastic idea.
I so hate country selection popups that have 200 countries in them, and United States is near the bottom even though 95% of their customers are in the US, or perhaps they don't even ship outside the US. So many sites do that and it is infuriating.
Another related problem for us Brits is that you sometimes end up doing a hunt up and down the list for one of "United Kingdom" -> "England" -> "Great Britain" -> "Britain" -> "British Isles" -> "The United Kingdom" etc. etc, whilst trying to remember all the different "synonyms".
Not true anymore. What you could do is add a hidden field with value=encrypt(timestamp+salt) and only accept the form if the decrypted timestamp is at most x hours old. If you want to further restrict it, you could also add the IP to the encrypted value. This will fail if a user gets a new IP between loading the form and submitting it (laptop user moving around, VPN gateway changes etc).
Granted, if they have a huge network of distributed bots, it probably won't help. But, if they do try to register a bunch of accounts using the same timestamp hash, it'd be easier to nuke all of them at once when you discover what's going on.
You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there.
Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.
One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.
If you get targeted specifically, then, yeah, the human in charge can figure it out in short order.
"You could also use Honeypot Captcha approach: you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots. When the form is submitted, you check to make sure the value of that form field is blank."
Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.
About 6 months ago, the new version of Chrome started auto-filling email addresses into my honeypot field, so it was a good thing I returned a friendly message (explaining that some auto form-fillers might cause this error, and needed to be temporarily disabled) rather than just assuming "bot".. but I still had some pissed-off people who had been trying to give me money and couldn't.
It's also worth noting that honeypot fields are only useful on a small site that is unlikely to be specifically targeted. A custom-tweaked bot can very easily bypass a honeypot field, of course.
You shouldn't be thinking about security in your validation anyway.
But I don't see the security cost in populating the username box with what the user previously typed there. We're just echoing back what the user typed. The only extra information we've provided is that the potential attacker can't login with that username+password --- we don't say whether this is because the username is invalid or because the password is incorrect for that username.
If I've gotten my username wrong, it's usually because I made a typo, in which case, re-typing it will solve the issue, or because I simply don't remember it, in which case, seeing what I typed previously isn't really going to help with that.
If you're on a community based site where others can see your username, there's no reason to hide it. Anybody trying to brute force your password is probably specifically targeting your account.
On the other hand, if you're on a service where other people cannot see your username, it would indeed be better to return a 'username or password does not match' error.
Require Users to Type Their Password Only Once
Allow Users to Auto-Fill Their Payment Address From the Shipping Address
Don’t Check the Newsletter Option by Default. Offer a Preview Instead
Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript
Allow Users to Unmask Their Password
Make the “Submit” Button as Wide as the Text Fields
Allow Users to Log in Via Facebook, Twitter or OpenID
But don't get me wrong I still think it's good to think about this stuff and don't take everything for granted, just because everyone does it. From that perspective it is a great post.
Your signup and login pages MUST be bulletproof.
Autofilling city/state from zip, for example, requires an updated database of postal codes, but users will often consider your autofill city as "wrong", since they use a different district/locale name. Make sure users can override your guesses.
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
If it just displayed in a textbox, game over...
> Web Developer > Forms > Show Passwords
You can also type your password into the username field first, then cut & paste it into the password field before entering your actual username.
Some years back while traveling and using dubious internet cafes I used to (I imagined) defeat keyloggers and at the same time navigate foreign keyboard layouts by typing my password mixed-up into the username field, then copy/pasting it a piece at a time into the correct order in the password field.
It should nonetheless be noted that many browsers cache values entered in non-password fields, so if someone is using a shared computer to register, the next person might only have to double-click on the non-hidden password field to see a list of previously entered passwords. Not so good.
Billions of people are all used to typing into masked (or unechoed) password fields, having done so in a wide range of UIs a shitload of times. Typing into a password field and seeing it reflected back feels like a slap in the face, the security context is irrelevant, it's just a massive discourtesy.
Your website is not going to be the very first thing the user has ever logged into. It is not your place to try to reinvent such fundamental things, changing this on your site is on the same level of jackass hubris as reversing the tab order or mouse coordinate system with javascript. All you're going to do is infuriate people.
For example... 1) Start capturing packets via wireshark. 2) Fill out the form. 3) Replay the captured packets, altering the username.
Presto, now you can sign up as fast as you want.
however, i have noticed some sites dont like the + which sucks because the spam model breaks down
I'm also interested in the elimination of the post sign-up confirmation email. I'd rather get a "Welcome! If you didn't sign up for this service, click here" email, but I can imagine that if I didn't actually sign up for the service, I'd never want to "click here" for fear of spam. There has to be another option, though. Anyone have any bright ideas?
You have to type it twice, because you don't see what you typed the first time -- it's a validation.
You don't see what you typed the first one, because that's "standard practice" for passwords, so that no one looking over your shoulder will see the password you typed.
That makes sense sometimes -- e.g., when you register for your new gmail at a starbucks. For me, 99.9% of the time, that's not an issue -- I'd much rather have a checkbox that says "press here to hide password".
But that's the standard practice.
It's especially important because a streamlined workflow will have both forms on the same page. It's infuriating to try to log in and get an "account already exists" error. HN is one of the very few sites that make this mistake.
I'm not quite sure about a checkbox to confirm password...maybe I need to see it actually implemented somewhere to know if I like it.
Not sure I love the idea, because there will be certain situations when a user can't use it, but it's worth considering...
In every other case it's your password that you type all the time (or paste). In the rare instance that you fuck up it's easier to enter it again than it is to fix it.
1). Email address - unlikely to be forgotten and is useful, ie you can then contact the user
2). Password - so the user can access the site. And I agree, dont ask twice for this, as long as you have a password reset feature.
Any further information can be obtained once the user is inside the system - and full explainations can be given as to why particular information is required.
And never use captcha! There are a millions tricks that you can employ to avoid bots.
As someone who uses LastPass, don't do this. It (usually?) won't let LastPass log you in to the site nor save the log-in details for a new site - a huge pain in the ass.
On another note, if I fail to enter the right details or check the right boxes, don't let me start all over again! Opera is great in how it lets you go back and retain all entered data, but other browsers are not as good at this.
Also, I google everybody, whether because I am reviewing your cv, or because you are a friend of a friend. Facebook connect is a definite no-no.
1. You always need access to email to get access to a website. This means that for whatever reason you don't have email access, you are locked out of all sites.
2. While it works from a security standpoint, you still add overhead to the users task. Users have to go between website and email and back to website just to log in.
3. slow connections might make the task even more cumbersome since you now add the delay of checking emails just in addition to logging into the website.
And yeah its a little more tedious if the site doesn't have a long session time.
In theory, you could just continue to click "Forgot password" every time you need to log in, indefinitely. Some sites that offer this sort of functionality, that's what I do.
What I hate is when the forgot password link FORCES you to change your password. If there's a forgot password link that lets me log in easily via email, then I see no reason to be forced to change my password.
I have problems with OpenID, too, because I tend to be unable to remember which OpenID login I used for a site.
Or maybe it was that Yahoo creates several OpenID logins?
Google turns up a Quora thing which, frankly, is full of handwaving bullshit.
Are there actual technical reasons why OpenID is bad?
And the reasons are mostly ones of user-friendliness (not technical reasons). I've heard of plenty of people who still never signed up for StackOverflow because it requires OpenID.
The abstract idea was good, the standard itself is awful.
You need look no further than any of the stackoverflow related sites to see a very successful large scale site using OpenID.
I'd also suggest looking at tripit.com, catch.com, mindmeister.com or springnote.com to see excellent examples of OpenID login done in a way that's very user friendly while also providing the option of a traditional login for people who prefer it.
As someone who talks to non-native English speakers, "check password," is triggering a burning rage within me. There is so much potential for misunderstanding.