Don't Make Visitors Make Accounts
benburwell.com
benburwell.com
Maybe you don't display it as an "account", but I can't think of a single commercial website where you shouldn't at least be taking an email address as part of the transaction. Yeah, users love to complain about registration, but I can tell you from direct experience that they love to complain even more loudly when they have a problem, and you can't find a history of their transaction because they never gave you a way to identify them -- I can guarantee that they never printed out your transaction record. Account-less purchases will have their way with you. Don't do it.
As for the rest of it, maybe it makes sense for you to provide OAuth options; maybe it doesn't. It really depends on the domain. Likewise, maybe it makes sense to offer "traditional" login, or maybe it doesn't (Tinder seems to be doing okay). The password advice is good.
Developers are this unique audience of people who have -- well, let's say "highly evolved" -- expectations about how web businesses "should" work. Most normal people don't share their expectations, so don't make assumptions without direct validation from your target audience.
I guess what bothers me the most about "advice" like this is what makes the person stating the advice qualified to give the advice? This is not to say it's right or wrong but with all due respect to all those on HN that are still in college (such as Ben the OP) why do you feel that you are uniquely qualified to offer this? Noting that you posted it to HN and not a third party that somehow tripped on it ...
OP do you care to give your thoughts?
These are simply usability guidelines that I've built up over my time interacting with hundreds of websites. I find myself annoyed by certain things over and over, so I decided to put them together in the form of a list. I don't believe I am more qualified to write this than anyone else who has spent a decent amount of time on the Internet.
Furthermore, there are always exceptions. I'm not implying (or I hope people are not inferring) that no site should ever provide a sign-in/account feature. You may have a compelling reason to provide this, and that's great. But don't allow or require people to do this when it offers them no value.
I think that when you say this (as you did in the blog post):
"here are a couple of rules to follow to ensure a good user experience:"
...particularly using "rules" you have to keep in mind that anyone and everyone could be reading your post.
And they very well might think that you are more qualified in your opinions than someone who has come to those conclusion by observation [1] and therefore give those "rules" greater authority than they deserve. Since, by your reply to my question, you say are actually just "simply usability guidelines that I've built up over my time interacting with hundreds of websites".
Now of course if you are a business offering to sell a product or service I for one think that it's a good idea to be definitive and state an opinion in many cases as if it's a fact. Regardless of whether it is or not. [2]
[1] Which of course we all do from time to time.
[2] But even with that I would never tell people in a blog post that this is a "rule" just something that I feel (and for what reason) is appropriate from my perspective.
So far,our testers love it. It seems to have gotten them quickly past the user dread. It also means your first participation in our site can happen by submitting one form and confirming one email. That's somewhere between two and five steps shorter than had we required account setup. While it adds an extra step to subsequent interaction, email confirmation, we feel like it's a good trade off for them. After all, going through a password reset when you come back to the site is an easy way to lose people.
And for us, it eliminated a lot of development headaches. When a user first participates in the site we assign them a randomly generated username. And they can change it to whatever they like ... They just fill put the change my username form and confirm by email.
Obviously, if we wanted to save credit card info or something like that we might need to modify this approach for PCI compliance, but I believe a fundamentally similar workflow could be employed even then.
> After all, going through a password reset when you come back to the site is an easy way to lose people
Most password reset forms I've seen just ask the user for their email, send them a link and ask them for a new password. This is nearly the same flow as your regular login flow, if I understand correctly?
It'd be similar to 2fa, but without the first factor (a password).... I work on a similar site, where each real interaction is a financial transaction... since there's no real need to login after that transaction, there's no password, they're buying a product, and that is delivered via email... no need for the hassle of creating an account to login with... an account is made with a random password under the covers, but it's never really needed.
I agree so strongly with the bulleted points made, that it made me imagine a standard, a symbol of compliance. Sites complying with all 6 points could use some sort of validator, like W3C.
Sites/apps that make me sign up for something trivial, sign up through FB only, won't allow me to use my global identifier (my email), or limit the length of my password, are often rejected (by me) out of hand. I simply don't have the time or the patience to deal with their special circumstances and they need me more than I need them, 99.9% of the time.
This is great consolidated advice.
Then #3 on the bulleted list of six points says, "Username = Email. Don't make people remember a username for your site. You may allow them to pick a username later on that can be used in lieu of their email address, e.g. as the URL for a profile page, but don't force them to use a username to log in."
It can make all the sense in the world to make "accounts" a very lightweight thing. But if you're taking payments or doing anything that might conceivably result in a user support request (e.g. storing user data or taking some action on their behalf), then you need to have some form of registration. And once you have registration, you'll need to have some way to prevent drive-by registration by total strangers -- otherwise you'll start getting complaints from people that some jerk/spammer signed them up for your site.
There are reasons that this stuff exists, and authentication always deserves careful thought.
I'm sick of accounts. Fuck accounts, I've got hundreds of the little shits, every one a looming security time bomb. Most of them I cannot delete. I've just stopped making them now, which locks me out of pretty much every new product, but I consider it worthwhile in exchange for not creating more accounts.
There are better ways of doing this shit though. For example, firefox hello does not require an account like skype does. It just makes a hyperlink with a unique ID, and I can share it.
If you need to track the customers transaction, why not link it to a unique URL?
Don't use a single round of any hash function, including SHA-256.
You shouldn't try to roll your own crypto, and you shouldn't try to roll your own password verification either. Use bcrypt and you'll get salting and you'll get a multi-round hashing process that has the ability to easily scale up in complexity as computing power continues to increase.
I like people offering help to others, but I read your article before you updated this... and I immediately wrote you off because of that.
It's great to offer advice, but can't seem to find any indication of what your experience is.
GAE won't let you upload and run modules that are C-based, so bcrypt is out of the question.
You can also either move the computation to the client over a secure channel, or have another challenge/response method in place. I've actually thought about having a bcrypt challenge/response (from a pool of known values at the server) in order to reduce abuse of an API structure or interface. It was a thought exercise in how to approach such a method better... It was actually a thought on how to approach something like a next generation hive/bittorrent protocol to reduce the attack surface a bit.
In any case, just be careful when you implement more secure hashes with a high compute cost... it can bite you in the ass if you aren't careful.
That's no excuse for using a worse hashing method. You need to rate-limit login attempts anyway to prevent (or at least make impractical) brute forcing / dictionary attack attempts. But it's a can of worms either way (next step is captchas because of tor / anonymizer proxies etc.).
According to http://www.cryptopp.com/benchmarks.html you could check ~6480 bytes of SHA256 in the time that it would take you to just set up your first blowfish check. If you're trying to brute-force an 8-character password, you're looking at 141 cycles per password for SHA256 and 114,950 cycles per password for a single round of blowfish.
Very much something that has gone un-noticed by developers for a long time, is that login systems are an obstacle and something to be avoided if we can. Login systems can not be solved with Single Sign On (SSO) / OpenID systems either. (Not all of us have FB/Google accounts, and never presume so) Every developer is scrambling to find a solution for the 'login problem', and completely overlook how login systems complicate things for their users. A lot of login systems suffer from Not Invented Here™ syndrome. Often online forms are a sort of 'mystery meat' where users don't know what to expect there. I once saw an account registration form asking to include an emoji character in my password, for example.
"Want to save your work? Create an account."
Creating an account can use FB/Google, or local login.
First demonstrate value, and people will gladly save their work.
Their new homepage looks to push you to sign up first though. There is still a link to "Unclaimed points > Sign up to claim your points" in the top nav.
They significantly increased their revenue by simply allowing customers to purchase without having to create account.
Our checkout process requires no existing account, so you click on the buy button, enter your name, email address and billing info, and you create a password at the end, after which you DO have an account. We feel that this is much better UX than most other ticketing sites that send you to registration forms before you can continue the checkout.
We used to receive many, many support requests from people who'd lost the email containing their tickets. We then added order history and the ability to download their tickets by logging into their accounts and this resulted in a massive drop in support emails.
Another key point is that most people realise they've lost the ticket email only a few hours before the event is about to start, so we get very panicky last-minute emails from people freaking out that they're not going to be able to get in. Just giving people the option to log into an account and retrieve their tickets not only dramatically reduces our workload but also provides them with peace of mind.
We're adding 3rd-party login shortly (primarily Facebook) but will keep email/password as an option. However, even with 3rd-party login, we'll still need to confirm the email address as most people are used to email as their delivery method.
Saying all this, most of the advice in the article is valid and we follow many of the points. Our username is the email address and we enforce HTTPS on all pages (with HSTS headers).
"Losing email" is a problem completely distinct from the UX question. Since "losing email" is more-or-less impossible in year 2015, it isn't a reason to force people to make accounts. There are other ways to deal with this problem.
Actually losing email is basically impossible but non-technical people still do it all the time. What they mean is that they can't find the email they are after. "I am not good at searching" is indistinguishable from "the email is gone".
My latest project was a sunglasses/eyewear design site, where people could design their own glasses (I had a tech stack on the backend to make the glasses in my studio - the company is an experiment in mass customization).
I went to great lengths to allow people to use the software without creating an account. In the end, I probably spent two weeks trying to get it to work properly with all the edge cases - saving the anonymous design when they do finally create an account, locking out certain features that required identity, appropriate warning dialogs when work was going to be lost, etc.
And I still had edge cases. I burned two or three weeks trying to accommodate account-averse people, then had to spend another two days yanking it. That effort was based on my personal distaste at having ten billion website accounts, a distaste probably widely shared here on HN and likely nowhere else.
(This isn't an argument with Ben's points - his example use cases clearly don't need accounts.)
* It's a single place for a compromise to occur - the devastation of a serious identity provider hack completely upends the security of huge swaths of the internet in a single shot
* Breaks in fedauth protocols and implementations, similarly, presents a large auth crisis for the entire Web
* It's a single place for legal or extralegal pressure for governments to access services and data on behalf of everyone
* It creates market friction. If federated login had been around in large numbers when Myspace was the big social platform we'd still be using Myspace for the sheer reason we need it to vouch for our identity. It makes the big fedauth players 'too important to fail'
One should consider options carefully and determine whether a good user experience can be offered without further centralizing the Web.
This has been a pet peeve of a vast number of web surfers for over 15 years now.
In the early days, this pet peeve created a backlash in the form of a custom. The custom went like this:
1. When confronted with an annoying site asking you to log in or register, first try the account name "cypherpunk" with the password "cypherpunk".
2. If that works, great.
3. If there is no such account, then create one, for the benefit of future visitors who participate in the custom. There are variations on this: pluralizing to "cypherpunks" and possibly using the "cipher" spelling.
Please atone for your evil ways and fix it to "cypherpunk".
Thx.
That said, having implemented this I can see why many services don't. It's an entire other case to consider when thinking about security, user experience, etc. and for many it could definitely be more trouble than it's worth. It's just a question of values if you make it a priority or not.
A ticketing startup is a good example of a startup which could be used without a dedicated user account. But that's the minority.
Most websites aren't special enough to warrant yet another account. Of course they need to keep track of people.
For example, it's interesting that a site within the past couple of minutes to sign into could use a local account, facebook or google... I clicked fb first, they wanted contact info and my full friends list... google, just my email... so I let it in with my google account.
I think it really depends... I wouldn't offer social logins without also having a local option, but it really depends on your audience.
And it also tells Facebook / Google etc what other sites you use, which is none of their business (not that they won't grab that info because of like buttons, analytics, embedded fonts or hosted JS but that's another matter).
It would turn into /g/ without the pictures?
I don't want my card details to be saved, and typing in my address and card number take less than a minute anyway. Newsletters almost universally go to spam because I'm not a landowner who has the disposable income to just buy arbitrary things that are advertised to me.
I think generally developers are aware of this, but they're chasing the few that do respond to such tactics.
Just think of the huge number of people have kindles with 1 click buy.
The 'few' indeed.
These are just usability guidelines, almost all of which are dealbreakers for me when I visit sites.
For example, when I use my password manager to generate a 64 char password for a new account somewhere, and get an error message saying "Please limit your password to 3 to 20 chars using only letters and numbers," I just have to laugh to myself.
I mean, think about what this tells you about the creators of that site.
I think this would be much better if it answered the question "Why?"
From the site owners perspective, they want the data. Maybe they sell it, or maybe they want to provide a nice user experience. Welcome back user, here is all of your information, we kept it for you so it is not lost. Thanks for rejoining.
In the end, it really depends on what kind of site and what kind of users you have. Sites will prob not choose to delete all the information they have, much to some of their users dismay.
I chuckled at that, since my bank limits passwords to exactly 6 alphanumeric characters.
& again as help text when they're logging in.
Constantly have to reset passwords on obscure sites because I don't remember that I've been forced to use, e.g. no symbols. No use just telling me that on sign-up & expecting me to remember 6 months later.
See what I did there?
Are readers of this piece supposed to follow the advice, like sheep, simply because they are told to? Or because they will get more usage? Or because it will make the world a better place? Or some other reason? We can only guess.
Similar with Paypal.
What's most frustrating, when you login it lets to enter as long password as you want. Which is when it leaves you wondering why your password does not work.
So removing this would cost them a great deal of money.
Fortunately, there are plenty of exceptions to this rule. For example, price comparison websites (I built, ran and sold one) need nothing of the sort, it's just a mediocre marketing tool (your users are much better at recommending your product than you are!).