Security on Allen's Dev Journal

A Tour of Hash Functions: From MD5 to Argon2 and Beyond

Mon, 16 Jun 2025 00:00:00 +0000

In a previous article, we explored the topic of salted password hashing. This time, we’ll expand on that by taking a broader look at the world of hash functions.

Hash functions are crucial tools in computer science and cryptography, essential for tasks like data integrity verification, digital signatures, and secure password storage. There is a wide variety of hash functions, some common and others less so. This article will introduce several of them, highlighting their characteristics and primary use cases.

Early Hash Functions

When we talk about early hash functions, MD5 and SHA-1 are the most widely known. (Of course, even earlier ones like MD4 and SHA-0 exist, but they have long fallen out of use). MD5 and SHA-1 were extremely popular in the 1990s and early 2000s, widely used for file integrity checks, digital signatures, and more.

Although they were once ubiquitous, they are no longer recommended for security-sensitive applications due to known vulnerabilities. Despite this, they remain popular. For instance, many software download sites still provide MD5 or SHA-1 checksums for users to verify that their downloaded files are complete and untampered with. This highlights a common phenomenon: even when a technology has known flaws—or even severe vulnerabilities—its popularity can ensure its continued use. It’s similar to the JPG image format, which, despite its shortcomings (no transparency, lossy compression, prone to artifacts), remains one of the most used image formats today.

So, what are their security issues? In short, both MD5 and SHA-1 are vulnerable to collision attacks. A collision occurs when two different inputs produce the same hash value. This means an attacker could potentially create a malicious file with the same hash as a legitimate one, thereby bypassing integrity checks.

Consider the file download verification scenario mentioned earlier. A website tells you a file’s hash is d41d (using just the first four characters for simplicity). You download the file, compute its hash, and it matches. Normally, you would feel confident that the file is authentic. However, an attacker could craft a malicious file that also produces the hash d41d and trick you into downloading it instead. After verifying the hash, you would mistakenly trust the file and run a virus. This could also be used to forge certificate files, leading to severe consequences.

Even so, executing a collision attack is still computationally expensive. This, combined with MD5’s widespread adoption and fast computation speed, means it is still used in many non-security-critical scenarios to quickly verify file integrity.

The SHA-2 Family

Due to the security flaws in MD5 and SHA-1, the SHA-2 family (including SHA-256, SHA-384, SHA-512, etc.) emerged as the new standard. SHA-2 functions are more complex in design and offer a much higher level of security. They are widely used in digital signatures, certificate authorities (CAs), and other security-critical areas.

When using SHA-2 to store user passwords in a database, it is standard practice to add a random salt. This prevents rainbow table attacks, where an attacker pre-computes the hashes of common passwords and stores them in a lookup table. By adding a unique salt to each password before hashing, the resulting hashes will be different even if two users have the same password, making such attacks infeasible.

Here is a C# example of hashing a password with SHA-256 and a salt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


using System;
using System.Text;
using System.Security.Cryptography;

static byte[] GenerateSalt()
{
 // The method below will show an obsoletion warning in modern .NET
 using (var rng = new RNGCryptoServiceProvider())
 {
 byte[] salt = new byte[16];
 rng.GetBytes(salt);
 return salt;
 }

 // You should use the following instead:
 // return RandomNumberGenerator.GetBytes(16);
}

static byte[] HashPassword(string password, byte[] salt)
{
 using (var sha256 = SHA256.Create())
 {
 byte[] passwordBytes = Encoding.UTF8.GetBytes(password);
 byte[] saltedPassword = new byte[passwordBytes.Length + salt.Length];
 Buffer.BlockCopy(passwordBytes, 0, saltedPassword, 0, passwordBytes.Length);
 Buffer.BlockCopy(salt, 0, saltedPassword, passwordBytes.Length, salt.Length);
 return sha256.ComputeHash(saltedPassword);
 }

 // Newer .NET versions also provide more convenient static methods, like SHA256.HashData().
}

You would then store both the salted hash and the salt in the database. To verify a password, retrieve the salt from the database, apply it to the user’s input, hash it using the same function, and compare it to the stored hash.

Don’t worry about the salt being exposed. Its purpose is not to be secret but to ensure the uniqueness of each hash, rendering pre-computed tables useless.

The SHA-3 Family

While SHA-2 resolved the security issues of its predecessors, it is still based on the same Merkle-Damgård construction. Concerned that cryptanalytic techniques could eventually be extended to break the SHA-2 family and with the rise of quantum computing, the U.S. National Institute of Standards and Technology (NIST) released the SHA-3 standard in 2015.

SHA-3 is based on a completely different design philosophy, the Keccak algorithm. It not only provides higher security but also offers flexible output lengths (e.g., SHA3-224, SHA3-256, SHA3-384, SHA3-512).

However, SHA-3 is not yet widely adopted. It currently serves more as a backup for SHA-2, ready to be deployed if a critical vulnerability is ever found in SHA-2. Furthermore, while it offers excellent security and flexibility, other specialized algorithms are often preferred for specific use cases like password hashing.

PBKDF2

To further increase the difficulty of cracking passwords beyond just adding a salt, we can introduce iterations. PBKDF2 (Password-Based Key Derivation Function 2) is a popular function that does exactly this. It increases the computational work required for a brute-force attack by repeatedly applying a hash function.

PBKDF2 takes a password and a salt and runs them through a hash function thousands of times. The more iterations, the more difficult it is to crack. It is commonly used for password storage and key derivation.

In C#, you can use the Rfc2898DeriveBytes class to implement it:

1
2
3
4
5
6
7
8
9


using System;
using System.Security.Cryptography;
using System.Text;

static byte[] HashPasswordWithPBKDF2(string password, byte[] salt, int iterations = 10000)
{
 using var pbkdf2 = new Rfc2898DeriveBytes(password, salt, iterations, HashAlgorithmName.SHA256);
 return pbkdf2.GetBytes(32); // Generate a 32-byte hash
}

bcrypt and Argon2

Unfortunately, even PBKDF2 can be vulnerable to attacks using modern hardware, especially the massive parallel processing power of GPUs. To address this, more advanced password hashing functions like bcrypt and Argon2 were developed.

bcrypt is a password hashing function based on the Blowfish cipher. It is designed to be slow and computationally intensive. A key feature of bcrypt is its adjustable cost factor, which controls the hashing time. Unlike simple iterations, the cost factor is exponential—incrementing it by one doubles the computation time. In C#, you can use libraries like BCrypt.Net-Next to implement bcrypt.

Argon2 was the winner of the Password Hashing Competition in 2015 and is considered one of the most secure password hashing functions available today. It is highly configurable, allowing you to tune its memory usage, iteration count, and degree of parallelism to provide robust security. Argon2 comes in three variants: Argon2d, Argon2i, and Argon2id, each designed to protect against different types of attacks. In C#, you can use libraries like Konscious.Security.Cryptography.Argon2.

BLAKE2

BLAKE2 is a relatively new hash function (published in 2013) that strikes an excellent balance between speed and security. It was designed to be faster than MD5 and SHA-1 while providing higher security than SHA-2. It is well-suited for file integrity verification and even password hashing.

Its high performance comes from leveraging modern CPU SIMD instruction sets (like SSE2/AVX), making it especially efficient on multi-core processors. It comes in two main versions: BLAKE2b (for 64-bit platforms, with a variable output up to 64 bytes) and BLAKE2s (for 8- to 32-bit platforms, with a variable output up to 32 bytes). It also includes features like a built-in keying mechanism, optional salt, and personalization strings, making it very versatile.

In C#, you can use libraries like BouncyCastle to implement BLAKE2:

1
2
3
4
5
6
7


using Org.BouncyCastle.Crypto;
using Org.BouncyCastle.Crypto.Digests;

var digest = new Blake2bDigest(512); // Output is 512 bits by default
digest.BlockUpdate(data, 0, data.Length);
var hash = new byte[digest.GetDigestSize()];
digest.DoFinal(hash, 0);

SM3

Finally, let’s introduce a Chinese national standard hash function: SM3. Released by the China State Cryptography Administration in 2010, SM3 is an independently designed hash algorithm that does not rely on foreign standards, which is significant for national and information security.

The SM3 algorithm produces a 256-bit hash value and is comparable to SHA-256 in terms of security and efficiency. It is designed to be resistant to collision and preimage attacks and is seeing increasing adoption in China, especially in the finance, government, and defense sectors.

Summary

The world of hash functions is diverse, with each function having its own strengths. From the early MD5 and SHA-1 to the modern SHA-2, SHA-3, PBKDF2, bcrypt, Argon2, BLAKE2, and SM3, every algorithm was designed with a specific purpose in mind.

Here’s a quick guide for common needs:

Data Integrity Verification: MD5, SHA-1 (for non-critical uses), SHA-2, BLAKE2
Password Storage: PBKDF2, bcrypt, Argon2
Digital Signatures: SHA-2, SHA-3

Why You Must Salt and Hash Passwords: A Journey to Secure Storage

Thu, 05 Jun 2025 00:00:00 +0000

The topic of salting and hashing passwords is a fundamental concept in security, but why is it so crucial? This article will guide you through the evolution of password storage, from insecure to secure, to demonstrate the necessity of salted hashing and how to implement it.

We’ve all heard that passwords should never be stored in plaintext. Instead, they should be hashed, and more specifically, salted and hashed. What is the purpose and necessity of this process? And how can we achieve it in C#? Let’s explore these questions by progressing from the least secure to the most secure methods.

1. Plaintext Storage

Let’s start with the most insecure approach imaginable: storing the password as is.

1
2
3
4
5
6


class User
{
 public int Id { get; set; } // Auto-incrementing primary key
 public string Username { get; set; }
 public string Password { get; set; } // Plaintext password
}

When we create a new user, the database stores the literal password.

1
2
3
4
5


var user = new User
{
 Username = "admin",
 Password = "123456"
};

This is incredibly dangerous for several reasons:

If the database is local (e.g., SQLite), anyone who gains access to the database file or decompiles the application to find the connection string can see every user’s password.
If the database is remote, attackers have numerous ways to access the data, including SQL injection, leaked SSH keys, exposed database backups, or other server vulnerabilities.

A plaintext password leak is catastrophic. It not only exposes private user information but also enables attackers to perform credential stuffing (using the leaked credentials to try and log into other websites). Therefore, storing passwords in plaintext must be avoided under all circumstances.

2. Simple Hashing (MD5 / SHA1)

Let’s upgrade our code to store a hash of the password using an algorithm like MD5 or SHA1.

1
2
3
4
5
6


class User
{
 public int Id { get; set; }
 public string Username { get; set; }
 public string PasswordHash { get; set; } // The password hash
}

We can create a helper class to handle hashing and verification:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class PasswordHelper
{
 public static string HashPassword(string password)
 {
 using var md5 = MD5.Create();
 var hash = md5.ComputeHash(Encoding.UTF8.GetBytes(password));
 return Convert.ToBase64String(hash);
 }

 public static bool VerifyPassword(string password, string passwordHash)
 {
 return HashPassword(password) == passwordHash;
 }
}

In this method, we hash the password with MD5 and store it as a Base64 string. To verify, we simply hash the user’s input and compare it to the stored hash.

Info: Why Base64? Storing the hash as a Base64 string makes it human-readable in the database, unlike a binary BLOB. String-based columns are also often easier and more efficient to index. Many modern hashing algorithms produce string-based outputs by default.

A stored password hash might look like this: ISMvKXpXpadDiUoOSoAfww==

This looks much safer than plaintext. Unfortunately, to an attacker, it’s only marginally better. This is because of rainbow table attacks. A rainbow table is a massive precomputed lookup table containing the hashes of common passwords. An attacker can compare the hashes in your database against their rainbow table to quickly find the original password.

For instance, the hash above corresponds to the plaintext “admin”. An attacker with a rainbow table could crack this password instantly. Don’t underestimate these tables; they can contain billions of entries. Unless your password is very complex, it’s likely vulnerable.

Furthermore, algorithms like MD5 and SHA1 are broken. They are susceptible to collisions, where two different inputs produce the same hash value. An attacker might not find your original password, but if they find another string (e.g., “qwerty”) that produces the same hash, they can use that to log in, as the server only compares the hash values.

3. Hashing with a Salt (SHA256)

To counter these attacks, we need to upgrade our algorithm and introduce a salt. We’ll use SHA256 (part of the secure SHA-2 family) and a unique, random salt for each user.

1
2
3
4
5
6
7


class User
{
 public int Id { get; set; }
 public string Username { get; set; }
 public string PasswordHash { get; set; }
 public string Salt { get; set; } // The salt
}

Now, we update our PasswordHelper:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


class PasswordHelper
{
 public static string HashPassword(string password, byte[] salt)
 {
 var passwordBytes = Encoding.UTF8.GetBytes(password);
 // Combine password and salt
 var combinedBytes = new byte[passwordBytes.Length + salt.Length];
 Buffer.BlockCopy(passwordBytes, 0, combinedBytes, 0, passwordBytes.Length);
 Buffer.BlockCopy(salt, 0, combinedBytes, passwordBytes.Length, salt.Length);

 var hash = SHA256.HashData(combinedBytes);
 return Convert.ToBase64String(hash);
 }

 public static bool VerifyPassword(string password, string passwordHash, byte[] salt)
 {
 return HashPassword(password, salt) == passwordHash;
 }

 public static byte[] GenerateSalt()
 {
 // A 16-byte (128-bit) salt is generally sufficient
 return RandomNumberGenerator.GetBytes(16);
 }
}

Tip: Modern versions of .NET provide convenient static methods like SHA256.HashData and RandomNumberGenerator.GetBytes, removing the need to create instances. In the past, you might have seen RNGCryptoServiceProvider, which is now considered obsolete.

By combining the password with a unique salt before hashing, every resulting hash is unique, even if two users have the same password. This renders rainbow tables useless.

The salt must be stored in the database alongside the hash. During verification, you retrieve the user’s salt and hash, apply the same salt to the entered password, and compare the results. Now, even if an attacker gets your database, they can’t use precomputed tables to crack passwords.

4. Using a Key Derivation Function (PBKDF2)

Salting with SHA256 is quite secure, but we can do better. An attacker who has your database can still attempt a brute-force attack against each individual password. They can’t use a rainbow table, but they can take one user’s hash and salt and rapidly try millions of password combinations.

To combat this, our next step is to make the hashing process intentionally slow. We can achieve this with a Password-Based Key Derivation Function (PBKDF2). C# provides an implementation in the Rfc2898DeriveBytes class.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class PasswordHelper
{
 public static string HashPassword(string password, byte[] salt)
 {
 // PBKDF2 with 10,000 iterations and SHA256
 using var pbkdf2 = new Rfc2898DeriveBytes(password, salt, 10000, HashAlgorithmName.SHA256);
 // Get a 32-byte (256-bit) hash
 return Convert.ToBase64String(pbkdf2.GetBytes(32));
 }

 // Other methods remain the same
}

Info: Rfc2898 is the standard that specifies PBKDF2. You must specify a hash algorithm in the constructor, as the overload without it is now obsolete.

PBKDF2 introduces an iteration count. This forces the algorithm to repeat the hashing process thousands of times. The higher the count, the slower the computation, and the more difficult it is for an attacker to brute-force the password. A count of 10,000 is a reasonable starting point today, but this number should increase over time as computing power grows. This drastically increases the cost for an attacker to crack even a single password.

5. The Gold Standard: BCrypt and Argon2

Unfortunately, the arms race continues. Attackers can use specialized hardware like GPUs or FPGAs to accelerate the calculations for algorithms like PBKDF2. This brings us to our heavy hitters: BCrypt and Argon2. These algorithms are designed to be “memory-hard,” making them resistant to GPU-based attacks.

Let’s look at BCrypt. Since it’s not in the .NET standard library, we can use a popular third-party library like BCrypt.Net-Next.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class PasswordHelper
{
 public static string HashPassword(string password)
 {
 // The work factor (12) controls the complexity
 return BCrypt.Net.BCrypt.HashPassword(password, 12);
 }

 public static bool VerifyPassword(string password, string passwordHash)
 {
 return BCrypt.Net.BCrypt.Verify(password, passwordHash);
 }
}

Notice that our User class no longer needs a Salt property. BCrypt generates a salt internally and includes it in the final hash string.

A BCrypt hash looks like this: $2a$12$lraBT1/lH3RiFXjQbywREutDElnBFaolPOEsDAvo1sjK2iRjwCAUi

This string contains everything needed for verification: the algorithm identifier ( $2a$ ), the work factor (12), the salt, and the hash. You only need to store this single string in your database.

Info: The work factor is a power of 2 that controls the computational cost (e.g., a work factor of 12 means 2¹² = 4096 rounds). The higher the factor, the slower the hashing. A value between 10 and 12 is common today.

But what if an attacker is still determined to use their powerful hardware? This is where we bring out our ultimate weapon: Argon2.

Like BCrypt, Argon2 requires a third-party library, such as Konscious.Security.Cryptography. The implementation details are similar to BCrypt—it also produces a self-contained hash string. However, Argon2 is considered even more secure. It was the winner of the Password Hashing Competition (2013-2015) and is designed to be highly resistant to brute-force attacks by being tunable across three dimensions:

Time cost: How many iterations to run (CPU-intensive).
Memory cost: How much memory to use (memory-hard).
Parallelism: How many threads to use.

Argon2 comes in three variants:

Argon2d: Maximizes resistance to GPU cracking attacks.
Argon2i: Optimized to resist side-channel attacks.
Argon2id: A hybrid version that provides resistance to both side-channel and GPU attacks. It is the recommended choice for general-purpose password hashing.

With a robust algorithm like Argon2, you can be confident that passwords are protected against even the most determined attackers using current technology.

Conclusion

In this article, we journeyed from the dangerously insecure practice of storing plaintext passwords to the modern, robust standards of password hashing. We saw how simple hashing is vulnerable to rainbow tables, how old algorithms are broken by collisions, and how salting defeats precomputation attacks. We then explored how key derivation functions like PBKDF2 and memory-hard functions like BCrypt and Argon2 raise the cost of brute-force attacks.

In practice, your choice of algorithm depends on your security requirements.

For a small, low-risk project, SHA256 with a strong, unique salt is a decent baseline that is easy to implement.
For any application where security is a priority, BCrypt or, even better, Argon2 should be your go-to choice. They represent the current best practice for securing user passwords.