We previously talked about applying the last 3 of the 4 basic operations of data persistence (read, update, delete). In this post I’m going to talk about user authentication, better known to most people as login and registration.

User Authentication

User authentication verifies the identity of a user attempting to gain access to a network or computing resource by authorizing a human-to-machine transfer of credentials to confirm a user's authenticity.

Authentication helps ensure only authorized users can gain access to a system and prevents unauthorized users from gaining access and potentially damaging systems, stealing information or causing other problems. Almost all human-to-computer interactions -- other than guest and automatically logged-in accounts -- perform a user authentication

User authentication can be as simple as requiring a user to type a unique identifier, such as a user ID or email, along with a password to access a system; known as Single-Factor Authentication. It can also be more complex, for example, requiring a user to provide information about physical objects or the environment or even take actions, such as placing a finger on a fingerprint reader; also known as Multi-Factor Authentication.

A straightforward process, user authentication consists of three tasks:

1. Identification. Users have to prove who they are.
2. Authentication. Users have to prove they are who they say they are.
3. Authorization. Users have to prove they're allowed to do what they are trying to do.

User Registration/Identification

As stated above, one of the processes of user authentication is identification. To be able to identify someone we have to meet them and get to know them. We can do this by asking them to tell us about themselves. The way to accomplish this is by giving the user a form to fill; The registration form.

On the admin side of my project, I created a register page. In it I ask all the questions that’ll help me be able to identify my user; Including their first names, last names, email addresses, phone numbers and their passwords. We also have to keep in mind case sensitivity. Do we need the emails or passwords to be case sensitive or not? For security its best to make the passwords case sensitive so they can be much trickier and advanced.

I know what you’re thinking and you actually have a point. You can’t just input your passwords anywhere; It’s really risky. Whenever a password is input by a user and stored in the site database, it goes through a process called hashing.

By dictionary definition, hashing refers to "chopping something into small pieces" to make it look like a "confused mess". That definition closely applies to what hashing represents in computing.

It's easy and practical to compute the hash, but difficult or impossible to re-generate the original input if only the hash value is known. It's difficult to create an initial input that would match a specific desired output. Thus, in contrast to encryption, hashing is a one-way mechanism. The data that is hashed cannot be practically "unhashed".

Storing Passwords is Risky and Complex

A simple approach to storing passwords is to create a table in our database that maps a username with a password. When a user logs in, the server gets queried and returns a result that contains a username and a password. We look up the username in the table and compare the password provided with the password stored. A match gives the user access to the application.

The security strength and resilience of this method depends on how the password is stored. The most basic, but also the least secure, password storage format is clear text.

As explained by Dan Cornell from the Denim Group, clear text refers to

"readable data transmitted or stored in the clear"

Storing passwords in clear text is the equivalent of writing them down in a piece of paper. If an attacker was to break into the database and steal the passwords table, the attacker could then access each user account. This problem is compounded by the fact that many users re-use or use variations of a single password, potentially allowing the attacker to access other services different from the one being compromised. That all sounds like a security nightmare!

The attack could come from within the organization. A rogue software engineer with access to the database could abuse that access power, retrieve the clear text credentials, and access any account.

A more secure way to store a password is to transform it into data that cannot be converted back to the original password. This mechanism is known as hashing. "We must guard user accounts from both internal and external unauthorized access. Clear text storage must never be an option for passwords. Hashing and salting should always be part of a password management strategy."

User Login/Authentication

The next process of user authentication is the actual authentication. A user has to prove to us that we know him or her or have met them before. They can do this by giving us their unique id and password or a fingerprint scan, facial recognition etc.

As you might have guessed in this and any project this is achieved with a form. We simply ask the user to input their email and password, then when they click enter, we send a query to the database confirming if those two entries exist and are correct. It’s important to keep in mind that the password you’re using to query the database has to be hashed with the exact same method as when it was being stored/created. Here’s some MySQL code that does something similar:

$result = mysqli_query($db, "SELECT * FROM admins WHERE email ='$myusername' AND password = '$mypassword' ");

If you noticed, user registration and login fall into the create and read operations of data persistence and the remaining two will have to be made as well. CRUD doesn’t just apply to static items; they apply to basically any object that is stored in a database.

User Authorization

The last main process of authentication is user authorization. In the last post I talked about how dangerous a delete query can be and how it isn’t a feature to be left to just anyone; Thus the idea of super admins. A super admin can be a user who can do everything available to the project. This is usually the direct owner of the project or the developer; It depends… For example, a sales girl can’t have the same access on an ecommerce site as the business owner.

Authorization for different users can be achieved in multiple ways but they are all similar. In every user row, there’s a column for authorization levels. This can be a number or an array of link or modules that particular user can access. Whenever the user logs in, only his or her authorized actions are visible, or the unauthorized would simply not work.

Sessions

A session is a period devoted to a particular activity. In our case this “particular activity” is one being logged into our site. In a project we need to make sure that once logged in the user won’t be logged out or forgotten throughout that particular browsing session. Some items also need to be remembered including the users name, id, phone number.

When you work with an application, you open it, do some changes, and then you close it. This is a Session. The computer knows who you are. It knows when you start the application and when you end. But on the internet there is one problem: the web server does not know who you are or what you do, because the HTTP address doesn't maintain state.

Session variables solve this problem by storing user information to be used across multiple pages (e.g. username, favorite color, etc.). By default, session variables last until the user closes the browser or they explicitly destroy it by logging out.

We can store these information in a normal variable but most likely it won’t be visible everywhere in the project and will be lost if we refresh the page…

Session variables hold information about one single user, and are available to all pages in one application.

Summary

User authentication is very important in any project because they grant privacy, personalization and make sure our system remains secure and clean. Without it we wouldn’t be able to enjoy apps like Facebook or twitter. There are many more security measures to be put in place, but these are the basics. All progress has been committed to GitHub as at the time of writing. Stay tuned for part 5, I’ll talk about Integrating a payment system, particularly Paystack. If you have any questions or contributions, please drop a comment. If you liked the article give us a like or a thumbs up.