Others

Bcrypt Generator And Hash in the Program for Password Comparison

PHP introduces a new password management API based on the Bcrypt Generator secure hash algorithm

The RFC “password_hash” has just been accepted and will be added to PHP 5.5

Why this new API?

Usually, when we talk about password hashes, users turn to md5 or sha, two algorithms that should no longer be used (many rainbow tables, flaws in the algorithm)

An effective solution to hash passwords is the use of bcrypt but unfortunately few developers use it especially because of the crypt () function of PHP which is not the easiest to use.

 This new API, therefore, fills this gap with a simple and effective solution to protect passwords.

 How does it work?

The RFC offers four new functions, two of which are of particular interest to us since they allow you to hash and verify a hash:

Code: Select all

  1. password_hash ($ password, $ algo, $ options = array ());
  2.  password_verify ($ password, $ hash);

To hash and verify a password, it’s very simple:

Code: Select all

  1. $ password = “password”;
  2. $ hash = password_hash ($ password, PASSWORD_BCRYPT, array (“cost” => 10));
  3.  if (password_verify ($ password, $ hash)) {
  4. echo ‘Password OK’; } else {
  5. echo ‘Password error’; }

You will have noticed the specification of a cost in the options; this cost defines the complexity of the password. The higher the cost, the longer the hash takes to obtain and therefore the harder to attack.

With this API, you no longer need to worry about random salts, everything is managed internally, and the developer only has to protect his password.

Future compatibility has not been forgotten since; thanks to password_needs_rehash it will be possible to rehash a password if the default algorithm evolves.

How to store your passwords in the database:

In short: Store passwords without any processing before saving in the database, this idea is to be avoided, because it does not provide any security, an attacker who would have access to the database would have access to all the passwords.

Encrypted (therefore reversible): This may seem like a good practice, but even if you are using strong encryption such as AES256, it is not a good idea. The main problem with this method is that it is necessary to have the key to decipher the precious sesames, if it is lost you will no longer be able to decipher the secrets and if it is stolen, the attacker will have no difficulty in decrypting passwords. There is therefore a good chance that the secret key will be stored on the server hosting the database.

By hashing them: Hashing passwords is the best method since it is non-reversible, this method allows you to create a fingerprint of the supplied string (the password) and to store this fingerprint in the database, this method is, therefore, the most recommended provided you use a robust hashing algorithm!

Hash Functions: Comparison OF Algorithms

This article discusses the hash algorithm which is certainly the most well-known although considered obsolete and insecure today, namely MD5, as well as those strong competitors’ bCrypt, sCrypt and Argon2 that SYNETIS currently advocates.

There are a whole bunch of other hashing algorithms out there, so some that are also considered robust such as PBKDF2, however, it is not possible to talk about all the algorithms, this article focuses on those that are most commonly supported natively. (such as bCrypt and Argon2 which are for example natively supported in PHP, which remains the most widely used web language on the planet).

MD5: Definitely the most famous hashing algorithm! Invented in 1991, a critical flaw was discovered in 1996 (It is possible to create collisions = a collision designates a situation in which two data has an identical result with the same hash function). MD5 has been considered completely obsolete since 2004, so it has been 15 years that we commonly use an obsolete algorithm, without the notion of “salt” or “loop”. The MD5 hash of the word “Synetis” will be as follows:

bfb970843b550b7ea910814dec14ffcd

bcrypt: Created in 1999, it is an algorithm considered robust even today, it wants to be resilient to attacks by CPU & GPU by integrating a salt as well as a cost (number of iterations to create the hash) natively. bCrypt ($ 2y $) hash of the word “Synetis” with 10 loop turns ($ 10 $) could be as follows:

$ 2y $ 10 $ H06aNwzet21CaZo96U8utOi9qq8.ag0nSp53q7QFdbTnZOowbEIZu

If we generate a new hash, it will not be the same, because it also includes a random salt for each generation!

sCrypt: Created in 2009, it is an algorithm which is also considered still robust today, just like bCrypt it also wants to be resilient to attacks by CPU & GPU, it wants to be a better choice than bCrypt generator today, it integrates new parameters, the memory cost, and the CPU cost, these two parameters make it possible to always better protect against parallelization and attacks by brute force.

If we generate a sCrypt hash of the word “Synetis” with a length of 32 with a CPU difficulty of 2014, a memory difficulty of 8, and a parallelization difficulty of 1, we will obtain for example this hash:

5ca4fe8fab9fb3d7331ec7ae60b30e109eca0ba53f50be6a62b77cdcb266ba9d

Argon2: Argon2 is “the new kid” who won the Password Hashing Competition in 2015, it is derived into 3 functions:

Argon2I: Optimized against side-channel attacks (related to attacks on the CPU), for example, Specter & Meltdown vulnerabilities

Argon2D: Optimized against GPU attacks

Argon2ID: To guard against attacks by auxiliary channel & GPU

Argon2 allows additional protection to sCrypt with Argon2I

Without going into details, here is an example of the number of hashes that an RTX2080Ti GPU is able to generate per second for these algorithms (Excluding Argon2 which is not yet supported by hashcat but whose results should be close to sCrypt).

Hash / s algorithm

MD5 551.2 GH / s

MD5 (+ salt) 229.9 GH / s

NTLM 3195.7 MH / s

bCrypt 88200 H / s

sCrypt 554.1 kH / s

The following diagram shows the possibility in terms of password breaking (without optimizations) with 448 RTX2080 GPUs (difficult to reproduce due to the necessary hardware), although sCrypt and Argon2 are not part of this diagram, we can clearly see that bCrypt generator is the one that poses the most resistance.

Also read: TOP 5 Mobile Applications That Are Useful For Businesses

Salt and Pepper:

To remedy the main problems of so-called “simple” hash functions (MD5, SHA1, SHA256, SHA512), “patches” have been invented, in particular:

The notion of “salt” is intended to be a randomly generated string concatenated with the password (as a prefix, as a suffix, or both, etc.). The salt is generally stored next to the hash (in a database for example), for simplistic algorithms. It is therefore up to the developer implementing MD5 for example, to code the management, storage, and generation of the salt himself. The downside is that if the database is compromised (SQL Injection), all hashes and salts are at the mercy of the attacker.

The notion of “pepper” is a global string for all users (unlike salt), and which is stored in the application source code (and not in the database).

Using these two methods, in addition to increasing the computation time required for brute force, eliminates the need for dictionaries of passwords & rainbow tables (anti-frequency analysis).

In short, these dictionaries contain a large number of hashes, so if we generate the md5 hash of the password “azerty” it will quickly be found in one of these dictionaries because it is a widely used password, but if we add a random and robust salt to this password such as Bb1 ^ v7 * o, this will improve the entropy of the password and the generated hash will not be present in a password dictionary.

For MD5 there are many uses with salt, for example it is possible to do md5 (md5 ($ pass) .md5 ($ salt)) or md5 ($ salt. $ Pass. $ Salt).

Problems and Solutions OF These Algorithms

Using the various parameters of bCrypt, sCrypt and Argon2 results in a longer hash calculation time than MD5, the higher these parameters, the more robust your hash will be, but this will also result in higher consumption of resources/time to create the hash, which can generally create two main problems:

Deny of service: In the case of strong parameters, an attacker could use the registration or connection functionality and enter very very long passwords in order to consume a large number of resources on the servers, by multiplying the requests, he would be able to crash the server!

To correct this problem, several solutions exist: Limit password size, 100 characters maximum seems to be a good limit. Use a captcha system on pages where it is important to limit brute force such as the login/registration page in order to limit multiple requests.

Impose a rate-limit (tarpit type) on these potentially consuming endpoints;

Time-based user enumeration: In the case of a bad implementation (verification of the existence of the user, then if this one exists computes a hash, otherwise error message) it is possible for an attacker to verify that a user exists, in case of short response, the user does not exist, in case of a long response, the hash will be calculated so the response time may be longer

To remedy this problem, it is, therefore, necessary to check if the user exists AND (and not THEN) to calculate the hash of the password provided.

The CVE “CVE-2018-15473” concerning the enumeration of SSH accounts is based in particular on this principle.

Conclusion

MD5 or SHA1 type algorithms should be banned from new developments, as they are subject to collisions that have been demonstrated in the past; and this even if a notion of salt, pepper, and loop is added to their use.

In terms of robustness against all-new crypto attacks against these algorithms, the current big winner is Argon2. However, this algorithm is considered “young” (2015). In general, in the world of cryptology, the age of an algorithm coupled with its robustness advocates above all. Thus BCrypt generator is an excellent current candidate dating from 1999. The youth of Argon2 still makes it unknown to the public, and therefore little implemented natively in multiple languages.

Read More: Financial Crises

Ventsabout

Ventsabout is the hub of information. We are providing you with valuable nonprofit information about the world. We are here to bring and elaborate on all the innovative ideas about Health, Technology, Business, Finance, Computer, and many more. Our goal is to spread the knowledge all around the world and everyone should know about technology.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Check Also
Close
Back to top button