Skip to content
This repository has been archived by the owner on Nov 3, 2020. It is now read-only.

Topic: Password hashing

sjagoori edited this page Jun 21, 2020 · 1 revision

Decoded: password hashing

Every login should have its obvious protection; password hashing. In order to guarantee the security of your user's accounts, it's wise (if not obvious) to hash their plain-text passwords to a hashed string.

In this concept, the plain-text password is fetched from a form in the HTML body. Once arrived in the server, it gets hashed by one of the many hashing libraries. With this style of cryptography, it's not just hashing the plain-text string with an encoding scheme. No, those can be easily bypassed with rainbow tables; a library with decoded words- these are often referred to as dictionary attacks.

In order to prevent that, a hashing function should utilize the concept of salting. The salt is a random value with a predefined length. Once the salt is generated, it gets combined with the hashed value. This process essentially obfuscates the original hash, making it hard if not impossible to use rainbow tables. In addition to that, hashes are encoded with robust hashing algorithms such as SHA.

Bcrypt

Bcrypt is a password-hashing library made in the 90's Niels Provos and David Maziéres. The function is based on the Blowfish cipher (which is pretty robust). It uses salting on its hashes as a layer of security against rainbow tables and other dictionary attacks.

Its main advantage over competitors is that it is based on the Blowfish cipher which allows the generation of lengths up to 448 bits. On top of that, having that in place it makes it harder for intruders to crack the hash because GPU's are not optimized for those amounts of bits.

PBKDF2

Just like Bcrypt, PBKDF2 is another password-hashing library. It's feature-rich and utilizes techniques. Its main difference to bcrypt is that it follows a different notion for their hashing, normally it would be hash$salt or salt$hash, but with PBKDF2 that becomes something like iterations$hash$salt. Utilizing that allows for future-proofing when computers are faster and can handle better iteration rates; therefore handle the iteration rate for that hash better.


So with that out the way, it comes down to preferences and what is important to our specific use case. For our dating app, the speed is not our main priority and the users are not constantly logging in and out- this will cancel out the need for a fast hashing function. Which favors Bcrypt, it is a notoriously slow hashing function, by doing that it essentially improves the randomness and eventually the hashing process. On top of that, it utilizes the Blowfish's block cipher instead of SHA- this means that rather than the entire input at once, the input gets hashed in blocks. By doing that you multiply the layer of security.

With all of that considered, we have chosen to implement Bcrypt for our project because we don't need PBKDF2's modular, fast, SHA-type hashing approach but instead do want the more secure Bcrypt hashing function.

The implementation

First things first, we need to include the library in our project. Using genSaltSync(n) we set the iteration rounds on the salt- making it extra random.

const bcrypt = require('bcrypt');
const salt = bcrypt.genSaltSync(10);

With the iteration rounds for the salt in place, we're able to finally hash some passwords! In this piece of code, we use the hashSync which hashes the password. As parameters, it takes a plain-text string and the salt.

bcrypt.hashSync(req.session.register.password, salt);

When logging in, the incoming value is in plain text but that's okay. We search and find the user's hashed password from the database and then use the compareSync method. As parameters, this method takes the hashed password, the plain-text password, and the salt. It does it's cryptographic magic and calculates whether the plain-text password matched the hashed password.

bcrypt.compareSync(hashedPass, inputPass, salt))

Source