Inside a “simple”​ authentication system

Inside a “simple”​ authentication system

Building an authentication system is hard. There are so many ways that a site can be compromised. The consequence of getting authentication wrong on your software can have a tremendous effect. On top of it all, user experience is another factor that dictates how successful your service can be.

While I am trying to build my side project, I realize that authentication is a huge scope of work. After reading through many simple tutorials on authentication on Express + Node.js or Ruby on Rails, I came to a conclusion that rolling out my own authentication system is simply a terrible idea.

Here is what I learned:

  1. CAPTCHAS against humanity

CAPTCHAS are there to help prevent dictionary/brute force trial-and-error bots. It is really simple to write bots to try different passwords on a login page. However, these are only implemented to make auto login as a bot with trial-and-error harder. Because there are anti-captcha services out there such as

2. Storing passwords

A simple way to compromise the user database is by storing the raw plaintext password. The right way would be to store a password is to turn a plain password into a long random string with a key derivation function which provides a “salt” and storing the “salt” in a separate table. The “salt” is there to protect against rainbow tables.

3. Checking password Strength

Without password strength requirements, it is easy to run into some average Joe users who will implement 1 of the top 500 worst passwords of all time shown here

Sometimes sites provide some visual strength meter to indicate whether a password is good or not. I strongly believe that it is ok but insufficient. For example, a password like “‘;lkjhgfdsa” might look good to a password meter but it is actually a simple password that comes from the 2nd row of your qwerty keyboard from right to left.

3. Secret questions

Secret questions are actually not very secure, in fact, it is a security anti-pattern. The average Joe will highly likely choose some ‘standard’ secret questions like mother’s maiden name and this is nowadays a simple trivia question with answers that can be found on Facebook or Instagram.

4. Forgotten Password Functionality

Remember that we talked about hashing a password with salt? We now have to make some robust functions to delete the original passwords and hash and salt a new user password. On top of that, this requires an implementation that provides a lost password code to a user’s email address.

5. Distributed Brute Force attacks

It is basically impossible to prevent a bot from trying to login to a website. The only thing a simple website can do is to prevent. Some advance attackers can try to login to a simple website many different times. Suppose this simple site has 1000 users, an attacker can try logging in with a common password against all 1000 users.

6. Rapid-fire login prevention

It does not take long to crack a weak password. It will only take days or hours to crack a password with symbols and letters and numbers with less than 8 characters long. What really keeps the password from being cracked is the delays between login attempts.

7. Session data

Once you are logged in as “hoosier_daddy” then the system needs a way to remember that “hoosier_daddy” is logged in. This requires some session data to be stored somewhere. To do so, we need to store the session cookie. These cookies can be hijacked from disk, network traffic or cross-site scripting attacks if it is implemented incorrectly. These should only be kept as a persistent cookie. When a really sensitive operation is involved, it is always better to ask for authentication from the user.

8. Two-Factor Authentication

Because the authentication system is there to try it’s best to prevent a comprise, it can still have possible ways to be exploited by an average Joe’s mistake. Passwords can be stolen from sticky notes, stolen notebooks, messenger, that tinder text, or phishing sites. Therefore, it is important to provide two-factor authentication which offers an authentication service that requires a user to type in a single-use code while authenticating into a site.

9. External authentication providers

Some users would like to login with external authentication providers like “Login as Google”. Which I believe is a great tool to mitigate authentication problems. However, it is not trivial to implement a mix of authentication with Google auth and your own authentication API.

Basically, if any of these problems are not solved properly when a production system rolls out to the public, the system is open to attacks.

But of course, there are existing solutions out there that can guide developers to build a better authentication system.

  • Auth0
  • AWS Cognito
  • AuthRocket

These solutions are called Authentication as a Service (AasS). Although they cost some money, it saves a typical developer a lot of time from implementing and managing the feature. Not to mention it solves most of the problems in this article.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store