Hashing, Salts and Pepper

Hashing, Salts and Pepper

Below is the explanation of how from a password we pass to the imprint that the password leaves when it passes through a function (almost always unary) that takes it and breaks it up (to hash). However, there are huge databases of many hashes (they are called rainbow tables) which could allow a computationally impossible passage (from the hash to the password) simply by searching the list of hashes. And then methods were invented to "flavor" the password: with a long string (salt) to append with a single character (pepper) making rainbow tables useless.


Hashing

A hashing algorithm is a complex mathematical function that transforms a stream of data into a seemingly random output string of fixed length. For example, these words produce the following hashes:

"hello" -> "5d41402abc4b2a76b9719d911017c592"

"world" -> "5be9797e265371185c8e77a15d02dc8e"


The same input string will always produce the same output string, but if the input string has changed, even by just one character, the output string will be completely different. Typically, encryption means encrypting data temporarily until a key is used to decrypt it. Hashing, on the other hand, is often seen as a form of one-way encryption, as it is not possible to trace the hash back to the original string. You can only generate a hash from the original string.

encryption VS hashing

  • encryption: from message to gibberish and back to message means encrypting data temporarily until a key is used to decrypt it.
  • hashing from message to incomprehensible text the last encryption step is missing (back to message)


Advantages of hashing

Hashing is especially useful for storing passwords. Instead of storing the original password, its hash is stored. When a user enters their password at login, a hash of the entered password is generated and compared to the hash stored in the database. If the two hashes are identical, the login is successful. Password hashing happens on the backend server side, not in the user's browser. When a user enters their password during the login process, the server receives the password in clear text and immediately generates the corresponding hash using a hashing algorithm such as SHA-256 or bcrypt. This generated hash is then compared to the hash stored in the database associated with the user's account. Be careful: it is said that the browser transmits "in the clear", but in reality the PASSWORD is encrypted. In fact, one of the main security measures to protect the transmission of sensitive information, such as passwords, is the use of HTTPS encryption. HTTPS (Hypertext Transfer Protocol Secure) uses an SSL/TLS certificate to encrypt data between the user's browser and the web server. This means that even if an attacker intercepted the communication, they would not be able to directly read or manipulate the encrypted data.


Knowing the hash of the password is not so useful

quickly Note: Even if you read the password hash from the database, you cannot use it to authenticate to the server. Knowing the hash does not mean knowing the password.

The hash is a one-way function, meaning you cannot reverse the process to get the original password. Even if you know the hashing algorithm used, it is not possible to trace the hashed password back to the original password. When a user authenticates to a server, the server calculates the hash of the password entered by the user. The server then compares the newly calculated hash with the hash stored in the database. If the two hashes are identical, the user is authenticated. This way, the server never knows the user's original password. It only knows the password hash, which is a sequence of random characters. One reason why it is important to store passwords as hashes is to protect your passwords in the event of a data breach. If passwords are stored in plaintext, an attacker who gains access to the password database can read all passwords. If passwords are stored as hashes, an attacker can only read the password hashes. Hashes cannot be used to restore original passwords, so passwords are still protected.

Vulnerability protection

While hashing is an effective technique for protecting passwords, there are some vulnerabilities that can be exploited by attackers.

Attacks based on rainbow tables

Rainbow tables are databases that contain hashes of common passwords and their original passwords. Attackers can use these tables to trace the hashed password back to the original password.

There are several hashing algorithms, each with its own characteristics and performance. Some more common algorithms include MD5, SHA-1, and SHA-2.

Note: The SHA-1 hash function is unary, meaning that it only takes as input the data from which to generate the hash and does not require an additional secret key. In simpler terms, SHA-1 operates on a single input, which is the message or data you want to hash. It does not require a separate secret key as other forms of encryption do, such as Keyed-Hash Message Authentication Code (HMAC)-based hashing, which involves a secret key along with the data.

MD5 is a 128-bit cryptographic hash algorithm developed in 1991. It is one of the most widely used hash algorithms in the world, but it has been shown to be vulnerable to collision attacks (When two texts produce the same hash, it is called collision) .

SHA-1 is another 128-bit cryptographic hash algorithm developed in 1995. It was replaced by SHA-2 as the NIST standard for cryptographic hash algorithms.

SHA-2 is a family of 256-, 384-, and 512-bit cryptographic hash algorithms developed in 2001. It is considered more secure than MD5 and SHA-1 and is the current NIST standard for cryptographic hash algorithms.

HMAC: NON unary hashing

HMAC is used for NON-unit (binary) hashing involving a secret key along with the data.

HMAC is a key message authentication (KMAC) algorithm. It uses a cryptographic hash function and a secret key to create a message authentication code (MAC). The MAC is then used to verify the integrity and authenticity of the data.

HMAC is a safe and reliable algorithm, but it has some contraindications.

One downside is that HMAC requires a secret key. This key must be stored securely and must not be disclosed to third parties. If the secret key is compromised, HMAC-protected data can be forged or modified.

Another downside is that HMAC can be slow. The MAC calculation requires a certain number of operations, which can slow down system performance.

Finally, HMAC can be susceptible to collision attacks. A collision attack is a cyber attack that aims to find two different inputs that produce the same MAC. If an attacker can find a collision, they can spoof the data protected by HMAC.

Slow hashing with bcrypt or Argon2

When generating a hash, being fast is a contraindication, because an attacker can generate many hashes in a short time.

Bcrypt is a cryptographic hash function designed to store passwords securely. bcrypt is a time-dependent hash function, meaning that the cost of calculating the hash of a password increases as time passes. This makes it more difficult for attackers to conduct brute force or dictionary attacks against passwords stored using bcrypt.

The cost of bcrypt is determined by the number of iterations that are performed during the hashing process. The default value is 10, but can be increased to increase security. A higher iteration value will make it more difficult for attackers to conduct brute force or dictionary attacks.

Argon2

Argon2 is a cryptographic hash function designed to store passwords securely. It was selected as the winner of the Password Hashing Competition (PHC) in 2015.

Argon2 includes a cost parameter, called "cost factor", which determines the complexity of the hashing process. A higher cost makes the hashing process more resource intensive, making it more difficult for an attacker to perform a brute force attack.

The cost is measured in units of time, and increasing the cost will increase the time needed to calculate the hash. This provides an additional defense against attacks that attempt to guess the password through brute force, making the process more expensive in terms of computational resources.

Argon2 is more flexible than bcrypt. Argon2 offers three variants that can be customized to meet the specific needs of an application.

Overall, Argon2 is a better choice than bcrypt for storing passwords securely.

Brute force attacks and dictionary

Attackers can also attempt to crack your password by repeatedly entering combinations of common characters or words found in dictionaries.

perhaps: a hash (as in the example 5d41402abc4b2a76b9719d911017c592) of 30 elements raised to 35 possible characters gives a 30 raised to the 35th possibility which is equal to 500315450989997070000000000000000000000000000000 00



Salting and Peppering

To mitigate these vulnerabilities, two additional techniques can be used: salting and peppering.


Salting

Salting involves adding a random string to the password before generating its hash. This way, even if two users use the same password, their hashes will be different. This makes it more difficult for attackers to use rainbow tables.

However, it is not good practice to use the username as salt (it could be

Using a username of a user as the salt value. It becomes easy to construct the rainbow table if the username could be guessed.

The wordpress case

Wordpress uses the same salts for all users and not unique salts for each user for several reasons

Efficiency: Using the same salt for all users is more efficient in terms of performance than using a unique salt for each user. This is because the salt is stored along with the password hash in the database. If each user had a unique salt, the database would be larger. Furthermore, the server would have to generate a new salt for each newly entered password, which would require more computing resources.

Security: While salts themselves may make it easier for attackers to conduct brute force or dictionary attacks, overall system security is not compromised if hashes are generated using a cryptographically strong hashing algorithm, such as SHA-256. This is because attackers would not be able to calculate users' original passwords even if they knew the hashes and salts.

Implementation: Implementing a salting scheme with unique salts for each user can be more complex and require changes to the core WordPress code.

Pepper

Peppering consists of adding another, very short, random string, a single letter, for example, called "pepper", to the hash generated after salting. The pepper is a secret string that is not stored in the database. This makes it even more difficult for attackers to trace the original password, even if they use brute force or dictionary techniques.

If it were just one letter (among the 26 possible uppercase and 26 possible lowercase letters), it would increase the possible hashes by 52 times, a small burden for the user, a mountain for random attacks!

For completeness, it is worth saying that there are two definitions of pepper (see wikipedia). The first is the one we used here (the second is also used by others):

  • pepper is a small, randomly generated value that is never saved; to check if the input is correct, the application iterates over the set of possible values that the pepper can take (to avoid timing attacks) evaluating the output of the hash function for each of these
  • the pepper is at least as long as the salt, is stored separately from the value to be hashed, and is often secret within the application

Conclusion

Using hashing, salting, and peppering is an effective combination to securely protect passwords. It is important to use a cryptographically strong hashing algorithm, such as SHA-256 or bcrypt, or set an appropriate cost value for Argon2. Appears also important to use a unique salt for each user and a secret pepper.

要查看或添加评论,请登录

Andrea Alessandrini的更多文章

  • Presenting Faster and More Focused

    Presenting Faster and More Focused

    Proposing a More Productive and Engaging Approach to Evaluation Meetings In many instances, we have all found ourselves…

  • Join the Beta Testing for the Appace iOS Application

    Join the Beta Testing for the Appace iOS Application

    Hi everyone. You probably already know me as the founder and leader of Ambiente Ingegneria, where I have provided…

  • Training Environment

    Training Environment

    I was wondering, which training environment do you prefer? Here mine. I recently discovered testdome (it kindly…

  • eIDAS example, between Spain and Italy

    eIDAS example, between Spain and Italy

    Recently I published a post about the European Rule called eIDAS, that's the short of electronic IDentification…

  • Supply chain management

    Supply chain management

    I always try to help people (organization, web pages, seller) to properly use international system units. The rules are…

  • Two Meetings: about professional update and risk analysis

    Two Meetings: about professional update and risk analysis

    I'm pleased to let you know about two meetings hold by me. In the first meeting, whose title is “The professional…

  • Risk analysis: version 2.0 of Risk-net

    Risk analysis: version 2.0 of Risk-net

    It is available version 2.0 of Risk-net.

  • Curso de Analisis de Riesgo con RBCA Tool Kit

    Curso de Analisis de Riesgo con RBCA Tool Kit

    La aplicación de la metodología de Acciones Correctivas Basadas en el Análisis de Riesgo (RBCA) para la gestión de…

社区洞察

其他会员也浏览了