Shulou(Shulou.com)06/02 Report--

This article mainly introduces the relevant knowledge of "what is the password encryption storage technology in web development". The editor shows you the operation process through an actual case, the operation method is simple and fast, and it is practical. I hope this article "what are the password encryption storage technologies in web development" can help you solve the problem.

From the earliest plaintext password preservation, to md5 sha1 sha256 sha512 encryption, to the addition of salt, pepper, multiple hash calculations, and then to the modern password encryption algorithm Bcrypt PBKDF2 Argon2id. In the process of protecting users' passwords, software engineers have made great efforts to contribute to the construction of network security.

Introduction

Most users use the same password in different sites or applications, so when the site's database is stolen, the stored password should not be obtained by the attacker. Like most areas of cryptography, there are many factors to consider; fortunately, most modern programming languages and frameworks provide built-in functionality to help store passwords, making the problem much easier.

Background hashing and encryption (Hashing vs Encryption)

Hashing and encryption are two terms that are often confused or misused. The main difference between them is that the hash is unidirectional (it is impossible to "decrypt" the hash value and get the original value), while encryption is bidirectional.

In almost all cases, passwords should be hashed rather than encrypted, as this makes it difficult or impossible for an attacker to obtain the original password from the hash.

Encryption is used only in extreme cases where the original password must be obtained. Some of the scenarios that may need to be done are:

If the application needs to use a password to authenticate an external legacy system that does not support separate login (SSO).

If you need to retrieve a single character from the password.

Being able to decrypt the password means a serious security risk, so a full risk assessment should be carried out. Where possible, alternatives should be used to avoid the need to store passwords in encrypted form.

This article focuses on password hashing. For more instructions on encrypting passwords, see Cryptographic Storage Cheat Sheet.

How does the attacker crack the password Hash

Although it is not possible to "decrypt" the password hash to obtain the original password, the hash can be "cracked" in some cases. The basic steps are:

Select a commonly used password (for example, "password").

Calculates the hash value entered.

Compare it with the target hash.

Repeat this process with all candidate passwords until a match is found. There are many different ways to select candidate passwords, including:

Brute force cracking (try all possible passwords).

A dictionary or vocabulary list of commonly used passwords.

A list of passwords obtained from other attacked sites.

More complex algorithms such as Markov chains or PRINCE.

Common patterns (for example, "1 uppercase letter, 6 lowercase letters, 1 number").

Hash concept (Hashing Concepts) plus salt (Salting)

Each salt is a unique randomly generated string that is added to each password during the hashing process. Because salt is unique to each user, attackers must use the corresponding salt to crack each password, rather than cracking the password of the entire database at once. This makes it very difficult to crack a large number of hashes, and the time required is proportional to the number of hashes.

Salt also prevents attackers from using pre-calculated rainbow tables. Finally, using salt means that it is impossible to determine whether two users have the same password without cracking the hash, because even if the password is the same, different salt can lead to different hashes.

Modern hashing algorithms such as Argon2 or Bcrypt automatically add salt to passwords, so no additional steps are required to use them. However, if you are using an old password hashing algorithm, you need to manually implement salting. The basic steps to do this are:

Use safe random numbers to generate salt. Use java.security.SecureRandom instead of java.util.Random ().

The length of salt should be at least 16 characters.

Encode the salt as a secure character set, such as hexadecimal or Base64.

Combine salt and password.

This can be done using simple stitching or HMAC.

Hash the combined password and salt.

Stores the hash value.

The generating method of safe Random number

Add pepper (Peppering)

In addition to adding salt, you can also add pepper to provide additional protection. It is similar to salt, but with four main differences:

All passwords share pepper, unlike salt, which is unique to each password. This makes pepper predictable and can try to crack passwords. The static characteristic of pepper also "weakens" the ability of hash to resist collision, while salt uses a unique string to extend the length, which improves the ability of hash to resist collision and increases the input entropy of hash function.

Pepper is not stored in the database, unlike salt (but salt is not always the case).

Pepper does not make password cracking too difficult to make an attack impossible, which is the goal of many other password storage protection measures, such as salt.

Salt prevents attackers from making rainbow tables of known passwords, but pepper does not.

The purpose of pepper is to prevent attackers from being able to crack any hash when they only get the database (for example, if they exploit the SQL injection vulnerability or obtain a backup of the database).

The pepper should be no less than 32 characters long and randomly generated using a secure random generator (CSPRNG) (for example, java.security.SecureRandom). Secure access API should be used to store it securely in the "secret file library" (not in the application's configuration file, because it is vulnerable to SSRF attacks), or pepper should be stored in the hardware security module (HSM) for the best security.

The use of pepper is similar to salt, splicing papper and password before hash, such as hash ($pepper. Password). Salt can be stitched, but papper can only be stitched in the form of a prefix. Do not use papper as a suffix, as this can lead to vulnerabilities such as truncation and length extension attacks. These threats make passwords pass authentication because unique passwords are never truncated, only papper is truncated.

alternative

Another option for pepper is to use the hash password as usual and then encrypt the hash using symmetric encryption, which is then saved to the database. This encryption acts as a pepper and works in a way that does not directly affect the password or hash. This avoids known problems with the concatenation / prefix method, and if you think pepper has been compromised, it allows the password to remain valid when you change the pepper key.

Another solution is to store pepper as ID. When the password is stored, the associated pepperID is saved to the database together. This makes it possible to change the pepper without revealing the pepper. When you need to replace the pepper, you can replace the previous value with the new pepperID. This requires the application to associate the pepperID with external storage.

Work factor (Work Factors)

The work factor is the number of hash operations performed for each password (usually 2 ^ work times). The purpose of the work factor is to make it more time-consuming to calculate the hash, thus reducing the cracking speed of the attacker. Work factors are usually stored with hash values.

When selecting work factors, you need to strike a balance between security and performance. A higher work factor will make the hash value more difficult for attackers to crack, but it will also slow down the login authentication process. If the work factor is too high, it will degrade the performance of the application, and attackers can also exhaust the server's CPU performance by making a large number of login attempts and carry out a denial of service attack.

The ideal work factor has no golden rule, it depends on the performance of the server and the number of users. Determining the best working factor will require experimentation on the actual server in use. In general, the calculated hash should be less than one second, but on sites with high traffic, it should be much less than this value.

Update work factor

With the passage of time, the performance of hardware continues to improve while the price continues to decline. According to Moore's Law, the work factor should be added by 1 every 18 months.

The most common way to update the work factor is to re-hash the password with the new work factor the next time the user logs in. This means that different passwords have different work factors, and if the user does not log back in to the application, the password hash may never be upgraded. In some cases, it may be appropriate to delete older passwords and require users to reset their passwords the next time they log in to avoid storing the older and less secure password hash.

In some cases, you may not need the original password to increase the work factor of hash, although common hashing algorithms, such as Bcrypt and PBKDF2, do not support this feature.

Maximum password length

Some hash algorithms, such as Bcrypt, have a maximum input length of 72 characters (some implementations are reported to be even shorter, but have not been determined at the time of this writing). In the case of Bcrypt, the maximum length should be limited to 64 characters, because it provides sufficient restrictions, still allows string termination problems, and does not reveal that the application is using Bcrypt.

In addition, due to the computational performance consumption of modern hash functions, if users can provide very long passwords, there may be a denial of service vulnerability, such as the one released in Django in 2013.

To prevent these two problems, you should set the maximum password length. For Bcrypt, it should be 64 characters (due to algorithm and implementation limitations), while for other algorithms, it should be between 64 and 128characters.

Limiting the maximum password length does reduce password space, but a limit of 64 characters still has at least 2 ^ 420 password space, which cannot be exploited by an attacker. Therefore, this does not significantly reduce security.

Pre-hash password

Another approach is to pre-hash the user-supplied password using a fast algorithm, such as SHA-256, and then hash the resulting hash using a more secure algorithm such as Bcrypt (that is, bcrypt ($password)). Although this method solves the problem that users enter arbitrarily long passwords, resulting in slow hashing algorithms, it also introduces some vulnerabilities that may make it easier for attackers to crack passwords.

If an attacker can obtain a password hash from two different sites, one using bcrypt (sha256 ($password)) to store passwords and the other using sha256 ($password), the attacker can use an uncracked SHA-256 hash from the second site as a candidate password to try to crack these hashes from the first (more secure) site. If passwords are reused between two sites, attackers can effectively strip off the Bcrypt layer and then focus on cracking the SHA-256 hash that is easier.

When using pre-hashing, make sure that the first hash result is safely encoded as hexadecimal or base64, because some hashing algorithms, such as Bcrypt, may run badly if the input contains null.

Because of these problems, the usually preferred method is to limit the maximum password length. Password pre-hashing should be performed only if there are specific requirements, and appropriate measures have been taken to alleviate the above problems.

Cryptographic hashing algorithm Modern algorithm

There are many modern hashing algorithms specifically designed for secure password storage. This means that they should be slow (unlike fast algorithms like MD5 and SHA-1), and you can configure how slow they are by changing the work factor.

There are three main algorithms:

Argon2id

Argon2 is the winner of the 2015 password hashing contest. There are three different versions of the algorithm and Argon2id variants should be used because it provides a balanced way to resist bypass attacks and GPU-based attacks.

Argon2 has three parameters that can be configured, rather than working factors that other algorithms can only set, which means that setting the correct parameters is more complex. If you cannot set the parameters correctly, you should use a simpler algorithm such as Bcrypt.

PBKDF2

PBKDF2 is recommended by NIST and has an implementation validated by FIPS-140. Therefore, when these algorithms are needed, it should be the preferred algorithm. In addition, it is available out of the box in the .NET Framework, so it is commonly used in ASP.NET applications.

PBKDF2 can be used with HMAC based on a variety of different hashing algorithms. HMAC-SHA-256 is widely supported and recommended by NIST.

The work factor of PBKDF2 is achieved through circular calculation, and the number of cycles should be at least 10000 (100000 may be more appropriate in more secure environments).

Bcrypt

Bcrypt is the most widely supported algorithm, and unless you have special requirements for PBKDF2 or knowledge of tuning Argon2, it should be the default choice.

The default working factor for Bcrypt is 10, which should usually be increased to 12 unless it is running on an older or less performing system.

Traditional algorithm

In some cases, modern hashing algorithms are usually not available because of the use of traditional languages or environments. If possible, third-party libraries should be used to provide these algorithms. However, if you can only use older algorithms, such as MD5 and SHA-1, many measures should be taken to improve the security of storing passwords.

Use the most powerful algorithm (SHA-512 > SHA-256 > SHA-1 > MD5).

Use pepper.

Use a unique salt for each password, generated using a secure random number generator.

Perform multiple hash calculations (at least 10000 times, more if the hardware performance is good).

It should be emphasized that these steps are not as good as using modern hashing algorithms, which should be used only if no other options are available.

Upgrade legacy hash

For legacy programs built using less secure hash algorithms, such as MD5 or SHA-1, these hashes should be upgraded to more modern and secure hashes. The next time the user enters a password (such as login), re-encrypt it using the new algorithm. It is best to expire the user's current password and ask them to enter a new password so that the hash of the user's password is no longer useful to the attacker.

However, this approach means that the old (less secure) password hash will be stored in the database until the next time the user logs in, and may be stored indefinitely. There are two main ways to solve this problem.

One way is to invalidate users who have been inactive for a long time and delete their password hash and ask them to reset their password to log in again. Although secure, this approach is not particularly user-friendly, and expired passwords for a large number of users can cause trouble for support personnel, or may be considered a violation by users. However, if there is a reasonable interval between upgrading the password hash at login and deleting the old password hash, most active users should have changed their passwords.

Another way is to use the existing password hash as input to a more secure algorithm. For example, if your application initially stores the password as md5 ($password), you can easily upgrade it to bcrypt (md5 ($password)). Hashes are layered in this way so that you don't have to know the original password. But as described in the "pre-hash password" section, this approach makes the hash easier to crack. Therefore, the next time the user logs in, you should hash directly with the user password to replace the old password hash value.

Custom algorithm

Writing custom encryption code, such as hashing algorithms, is really difficult and should never be done outside of academic activities. Any potential benefits that may be brought by using unknown or custom algorithms will be greatly undermined by the weaknesses in them.

Don't do this (Do not do this)

Java Hash implementation (Hashing Java) code example public static byte [] hashPassword (final char [] password, final byte [] salt, final int iterations, final int keyLength) {try {SecretKeyFactory skf = SecretKeyFactory.getInstance ("PBKDF2WithHmacSHA512"); PBEKeySpec spec = new PBEKeySpec (password, salt, iterations, keyLength); SecretKey key = skf.generateSecret (spec); byte [] res = key.getEncoded (); return res } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {throw new RuntimeException (e);}} Code Guide

The password and salt parameters are arrays and are determined by the hashPassword function. After use, you should clear sensitive data (set array elements to zero).

This example uses Password Based Key Derivation Function 2 (PBKDF2), as described earlier.

The salt parameter should be a random number, unique for each password. The length should be at least 32 bytes. Remember to store the salt with the password hash!

The iterations parameter specifies how many hash calculations PBKDF2 performs. The higher the value, the safer it is. You need to experiment on the actual running hardware. Find a value that takes half a second to perform an encryption operation. Remember to store the iterations value with the password hash value!

The keyLength of 256 is safe. (a 32-bit hash is generated)

If the sample code throws a NoSuchAlgorithmException exception, you can replace PBKDF2WithHmacSHA512 with PBKDF2WithHmacSHA1. Both are good enough for the task, but when people see "SHA1," you may be criticized (it's not safe to use SHA1 outside of PBKDF2).

Since JDK version 1.4, the SecretKeyFactory and PBEKeySpec classes have become part of Java SE.

This is the end of the introduction on "what are the password encryption storage technologies in web development?" Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.