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.
Prove you're not a robot
Which dog is the tastiest snack?
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.
▼ Response Headers
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.