Rust Broken
Authentication Guide:
Examples and Prevention

Rust is a fast and reliable language that supports asynchronous, and it is quickly becoming the premier choice for performance-focused network and web applications. Authentication is the process of verifying the identity of a user, and it's an integral part of software development. For example, people trying to get access to the system must prove that they're legitimate users. This way, unauthorized users won't get access to the system. 

For a language with high performance like Rust, what happens when authentication is broken? This means that cybercriminals can impersonate a legitimate user to cause havoc to the system. When this happens, the system is vulnerable to attacks. In this article, we will explore broken authentication, the different types, and how to avoid them in Rust applications. 

What Is Authentication?

Authentication recognizes and verifies the identity of a user, and it happens at the start of the application. The user provides their credentials, which the system can compare with what's in the database. For example, the credentials are usually a match of the user's username and password. If the credentials don't match that of the database, the user won't get access to the system. This is because the system will consider them an illegitimate user. 

While there are different means of authentication for different systems, users must provide a means of identification. For example, the credential must not be a password or an email address. User authentication is in three categories: The system will authenticate the user according to who they are, what they know, and what they have. 

What Is Broken Authentication?

Applications are prone to vulnerabilities that can cause a security breach. Broken authentication is one such vulnerability.

Broken authentication consists of vulnerabilities that cybercriminals can exploit to impersonate legitimate users. Sometimes, these vulnerabilities can be a result of developer error or from APIs (application programming interfaces) in the application. For example, if the application uses an API with a security breach, it could inherit them. Also, if an application uses a library that's vulnerable to authentication, it can cause a security breach.

Broken Authentication Types

There are different types of broken authentication vulnerabilities. In this section, we'll explore the different ways authentication can be porous and cause a vulnerability. 

Predictable Login Credentials

Sometimes, users choose credentials that are easily predictable. For instance, passwords like "Admin" or "Password1" can be easily predictable for cybercriminals. A downside to this is that attackers can easily get hold of the user's account. 

For example, criminals can apply brute force attacks until they can get access to the account of the user. A brute force attack isn't the only way attackers can get into a user's account. If the user permits a weak credential recovery process, the attacker can intercept the credential. 

Sensitive Data Exposure

While software development firms try as much as possible to protect user data, sensitive data is vulnerable to exposure in many ways. For example, user login information can get exposed before they get to the database. Also, during password recovery when users forget their credentials, they could get exposed. 

Sometimes, encryption doesn't protect user data from exposure. This is because attackers can decrypt data that has been poorly encrypted. For instance, research shows a vulnerability in version 1.0 that can allow attackers to decrypt data passing between a web server and the user. 

Session Hijacking 

Session hijacking is a term that describes when an attacker successfully takes over a legitimate user's account. With this move, the system thinks the attacker is the legitimate user and they get access to all user information. 

Session hijacking happens when attackers compromise session tokens. These session tokens are unique strings of data that only the server and browser know about. This is for network communication, where the server trusts a session token from a browser and allows the user access. In session hijacking, the attacker can take over the user's session after the legitimate user has logged in. Session hijacking is different from session fixation. The former hijacks a user session after the user logs in, while the latter launches an attack before the user logs in. 

Rainbow Attacks

Rainbow attacks are a series of attacks that target an application's database. When attackers target the database, they can get user credentials and let themselves into the user's account. A rainbow table is a table of reversed hashes that attackers can use to collect password hashes and decode them. 

Session ID Vulnerability

Session ID vulnerabilities exploit the fact that some systems allow attackers to get a valid session ID and then manipulate users to authenticate themselves with the session ID. 

How to Avoid Broken Authentication in Rust

We've explored the different broken authentication types in Rust applications. In this section, we'll discuss how to avoid them. 

Encrypt Password and Add Salt to Hashes

Credential encryption can go a long way in protecting user data from exposure. For instance, if an attacker gets hold of a user's credentials, they'll have to decrypt it to a human-readable string. In Rust, developers can use libraries like rust-fnv to hash user credentials. Here's an example of how to use this Rust library in a hashtable or HashSet: 

// Hashtable
use fnv::FnvHashMap;

let mut map = FnvHashMap::default();
map.insert(1, "one");
map.insert(2, "two");

map = FnvHashMap::with_capacity_and_hasher(10, Default::default());
map.insert(1, "one");
map.insert(2, "two");

// Hashset
use fnv::FnvHashSet;

let mut set = FnvHashSet::default();
set.insert(1);
set.insert(2);

set = FnvHashSet::with_capacity_and_hasher(10, Default::default());
set.insert(1);
set.insert(2);

What this does is use the FnvHashMap and FnvHashSetwhich to store a hash of credentials in a HashMap or HashSet. Sometimes, firms only want to hash the user's password. For this, they can use Rust's bcrypt library. An advantage of using this library is the addition of salt to hashes. Here's how to use the bcrypt library:

Use Passwordless Authentication and Session Invalidation

To avoid credential exposure, many firms are using passwordless authentication. In Rust, users can incorporate this with the Auth0 passwordless feature. This feature allows you to authenticate a user by sending a magic link or code to them. This magic link/code can be sent to the user's email address or phone number.

However, what happens when attackers launch a series of attacks to hijack the user's session? This is where session invalidation comes in.

For example, when an attacker tries to use the account, they'll be logged out because the session is invalid. To do this, developers can incorporate either of the methods below: 

Session Time-Outs

Developers can stop session hijacking, session fixation, and other attacks that can result from vulnerable session IDs by incorporating session time-outs. A session time-out is the time window when the user is inactive. When a user logs in to their account and stays inactive for a long time, attackers can steal user credentials or even hijack their session. What session time-outs do is lay out a time where the user will be logged out if they remain inactive. 

In Rust, most libraries have the time-out traits for their sessions. For instance, in Rust's yubihsm crate, developers can use the time-out struct in the session module. This allows them to create a new time-out by setting the duration of the time-out. 

Conclusion

Rust is an amazing language when it comes to security. For example, the compiler gives out errors like type errors when the developer makes a wrong choice. However, what happens when there's no compile-time error but users are making an error that'll cause a security vulnerability? This is where monitoring tools like StackHawk come into play. For instance, they can capture unsafe code that might lead to broken authentication. With StackHawk, you can also test APIs and third-party libraries in your application for security. 

This post was written by Ukpai Ugochi. Ukpai is a full-stack JavaScript developer (MEVN), and she contributes to FOSS in her free time. She loves to share knowledge about her transition from marine engineering to software development to encourage people who love software development and don't know where to begin.