The first thing to consider is: do you really need to build
your own authentication system? Facebook, Twitter, Google
and others offer mature OAuth implementations.
Implementing a "Log in with Facebook" button offloads the complexity
of authentication management to a trusted third-party, and makes the
login process very convenient for your users.
Some sites refuse to reset a password to a value that was previously
used. The intention here is good. However, most users will simply
append a number at the end of the password where repeated passwords are
not allowed.
Which brings us on to another subject: how to implement password
resets? The industry standard is to allow users to send themselves
password reset emails.
Password reset links should time-out in a reasonable time-frame.
Imagine if a hacker gets access to your user's emails - the first thing
they will do is try to compromise their other online accounts,
and long-lived password reset links make this easier.
Your site will typically implemented two password reset screens
- one for logged out users (after clicking on a password reset link in an email),
and one for users already logged in. Ensure this latter screen requires
re-entering of the user's old password, in case they leave themselves
logged in on a shared computer.
Password storage is also a complex subject. There
are some basics you need to get right.
Never store passwords in plain-text. Always use a
one-way hashing algorithm to encrypt your stored passwords.
This will protect your users even if your database gets hacked.
Choose a strong hash like BCrypt.
Storing the password hash will allow you to test the correctness of a
password when a user re-enters it, but keeps it opaque to anyone who
has database access.
Remember to "salt" your passwords too. This means
adding an element of randomness to each encrypted password so they can't
be backwards-engineered from lookup tables.
Social media authentication isn't suitable for all applications, of
course. If you find yourself implementing your own authentication,
the first thing to consider is your password complexity rules.
Passwords need a minimum length (8 characters is good). Many sites
require mixed case, numeric characters, or special symbols in an effort
to encourage less guessable passwords.
Bear in mind that your users are creatures of habit, and can
only remember a limited number of passwords. Many users will
simply capitalize the first letter, put a number at the end, or append
a ! to their password, when asked to make it more
complex.
Even worse: if your password complexity rules are too arduous users
will resort to writing their passwords down, which undermines the effort
you are putting in to make them secure.
Secure sites often implement a password lockout
period after too many failed login attempts. This is to discourage
brute-forcing of passwords, where an attackers submits
a lists of common passwords against known usernames.
This opens up the possibility of a malicious user intentionally
locking out a named account, though, so forcing the user to pass a
CAPTCHA test may be better.
Good password management needs to be paired with good session
management. Remember to implement session timeouts, or you
risk having your users' accounts compromised if they forget to press
the "logout" button.
Also consider whether you want browsers to cache passwords
on your login page. There is a trade-off between convenience
and security here. Think carefully what is most important for your
application - and be aware that browser settings or password manager
plug-ins may override your suggestion not to cache passwords.
Lastly, make sure your site uses HTTPS and marks cookies as
Secure
.
Unencrypted communication is vulnerable to network-sniffing,
meaning passwords could be stolen in transit by man-in-the-middle attacks.