A Humble Guide to a Password Authentication Implementation
Introduction
Password authentication is the most widely used authentication method. At first glance, it is easy to implement. It’s just two fields in an authentication form. But the two fields in an authentication form is just the tip of the iceberg. In following article, we will cover almost everything related to password authentication. Of course, not all the steps in the following article are necessary. Implementation depends on your application requirements and environment.
Database
First, you need to set up a database to store users credentials. It can be either SQL or NoSQL database, depending on your needs. The only requirement it should be highly available, because authentication is the mission-critical part of any application. It is strongly recommended to separate the authentication database from other databases and implement maximum security measures to that database. Users identifiers logins, and passwords hashes are stored in the database. In some cases, user identifiers acts as a user login.
Note: Each password should be hashed with a salt, associated with the user. We will discuss password hashing in the next section.
Password Hashing
A user’s password should not be stored as plain text, because if a user database is leaked, there is no effort for an attacker to use leaked passwords for malicious actions. To prevent this, passwords should be hashed and it is also strongly recommended to use hashing with salt to prevent a usage of hashes dictionary.
Hashing is a one-way encryption algorithm, that calculates a value based on an input.
When passwords stored as hashed values it makes harder for an attacker to guess a user’s password. Salt is a randomly generated value stored along with the password as plain text.
When a password hashed with a salt, it prevents the attacker to use popular passwords and their hash values and guess the password using hashed password. According to recent researches, It is recommended to use BCrypt or ARGON2 algorithms for password hashing.
Registration
To authenticate in your application a user should create an account. This process is called the registration process. The user enters his login and password into the registration form and submits the credentials. The server checks whether the user login exists, and if not, generates salt, hashes the password with a particular algorithm, and stores user authentication data in the database.
During the registration process or later a user should be able to set his email or phone number to further password recovery or critical operation notification. The channel should be confirmed via link or one time password sent to the channel to ensure the user has access to the channel.
Note. If the entered login exists, the server should respond with a significant delay, to prevent login brute force and allow an attacker to detect whether an account with such login exists or not.
Authentication
During the login and password authentication process, the user enters a login and a password. Authentication service searches the user record by login in the database. If the record exists, it takes salt, hashes entered password with the salt and matches it with the stored hash. If the hashes match, authentication is successful.
Note. Whether a user was not found by login or the password is invalid, the authentication error should always be the same (something like “invalid login or password”) to prevent the attacker to guess registered logins.
Note. To prevent guessing user’s password by infinite login attempts, authentication service should implement a lock policy, to block user accounts for a certain period of time for authentication.
Password Recovery
Users often forget their passwords, so they need a password recovery mechanism. So, they should enter either a confirmed email or phone number, and a password recovery link will be sent via this channel. A link should contain either encrypted password recovery data such as user login or link expiration time. Another way is to generate a password recovery session and encrypt the session identifier in the link.
Password Reset
There could be cases, when the user password is compromised, so it should be reset by organisation staff. It is a wide used practice to generate a temporary password and send it via email or another trusted channel. After the user entered his temporary password, the authentication system should ask the user to enter the user’s permanent password.
Change Password
Sometimes, users need to change the password. There are some reasons for it, the password could be compromised, and the user has an active authenticated session but forgot the password. So it needs to be changed. It is a good practice to notify users about password changes via the trusted channel, so if the password was changed by a hacker, a user will know it and will contact support to prevent further malicious actions.
Conclusion
In this article we have just covered the main password authentication features. Some of them are necessary, some are not. Password history control, password expiration, and password complexity policy are not covered in this article. As you can see password authentication is not quite easy to implement, as it seems at first glance. It is much easier just to pick a well-maintained open-source existing solution that could be integrated into your environment.
