1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
---
title: Your Website is not Special, Don't Make Visitors Make Accounts
description: >
Few things bother me more than when I am forced to make an account to have
some basic interaction with a website.
---
One of my pet peeves in website usability design is forcing people to create
unnecessary accounts. My recent purchase of some concert tickets from Ticketfly
required me to make an account to buy them. For people who buy a lot of concert
tickets, having an account may make a lot of sense. But for me, as someone who
buys concert tickets at most once every year or two, having an account on a site
that I will probably only use once is not only unnecessary, it's annoying.
<!--more-->
This is not to say that you shouldn't offer accounts; that would be ridiculous
(depending on the type of site you are running, of course). However, in general,
your users know far better than you do whether or not they actually want or will
use an account. Forcing them to create an account will only drive them away.
People don't like creating accounts they don't want to have. There's really no
reason you can't have a "check out as guest" option.
And if you do offer accounts, here are a couple of rules to follow to ensure a
good user experience:
1. Allow the option of using a 3rd-party identity provider (OpenID, Facebook,
Google, etc.). Often, visitors don't want to have yet another
username/password to remember.
2. Don't force visitors to use a 3rd-party provider. Always have a local option.
As a counter point to (1), many visitors won't want to use their
Facebook/Google accounts for authenticating to other sites.
3. 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.
4. Don't make complicated password rules. If you do have password requirements,
show them to the user _before_ they try to make a password. Only telling them
when their password doesn't fit your requirements causes consternation.
5. Never _ever_ limit how long a password can be (within reason, obviously you
don't want to be receiving a megabyte long password). My bank limits
passwords to 14 characters, which is rather absurd. Since you're hashing your
passwords anyway, it's not like you need to allocate extra memory in your
tables to store longer passwords.
6. Always allow your users to close their account. This should remove all
information about them from your service to the extent possible without
disrupting the integrity of other information.
Of course, there are technical details that you need to be watching out for that
are outside the scope of this post. I'll leave it to you to make sure your
implementation is secure and robust, but I'll leave you with a few general tips:
- Don't invent your own crypto. This applies to protocols, hashing, encryption,
everything.
- [Use bcrypt][bcrypt].
- Using unsecured HTTP (no SSL/TLS) is inexcusable.
- Don't invent your own crypto.
- _Don't invent your own crypto._
- **[Use bcrypt][bcrypt].**
[bcrypt]: https://codahale.com/how-to-safely-store-a-password/
|
