nodejs/nodebestpractices
1
0
Fork 0
mirror of https://github.com/goldbergyoni/nodebestpractices.git synced 2025-10-28 11:35:59 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update and rename bcryptpasswords.md to passwordhashing.md

Browse Source 
Presenting the tradeoffs between the IETF's and OWASP's top recommendations, as well as adding mention of making your implementation unique.
This commit is contained in:
Josh
2020-10-07 16:29:59 +00:00
committed by GitHub
parent 7636c01193
commit b7ed553652
2 changed files with 82 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
sections/security/bcryptpasswords.md
View File

@ -1,32 +0,0 @@
# Avoid using the Node.js Crypto library for passwords, use Bcrypt
### One Paragraph Explainer
When storing user passwords, using an adaptive hashing algorithm such as bcrypt, offered by the [bcrypt npm module](https://www.npmjs.com/package/bcrypt) is recommended as opposed to using the native Node.js crypto module. `Math.random()` should also never be used as part of any password or token generation due to its predictability.
The `bcrypt` module or similar should be used as opposed to the JavaScript implementation, as when using `bcrypt`, a number of 'rounds' can be specified in order to provide a secure hash. This sets the work factor or the number of 'rounds' the data is processed for, and more hashing rounds leads to more secure hash (although this at the cost of CPU time). The introduction of hashing rounds means that the brute force factor is significantly reduced, as password crackers are slowed down increasing the time required to generate one attempt.
### Code example
```javascript
try {
// asynchronously generate a secure password using 10 hashing rounds
const hash = await bcrypt.hash('myPassword', 10);
// Store secure hash in user record
// compare a provided password input with saved hash
const match = await bcrypt.compare('somePassword', hash);
if (match) {
// Passwords match
} else {
// Passwords don't match
}
} catch {
logger.error('could not hash password.')
}
```
### What other bloggers say
From the blog by [Max McCarty](https://dzone.com/articles/nodejs-and-password-storage-with-bcrypt):
> ... it’s not just using the right hashing algorithm. I’ve talked extensively about how the right tool also includes the necessary ingredient of “time” as part of the password hashing algorithm and what it means for the attacker who’s trying to crack passwords through brute-force.

82
sections/security/passwordhashing.md Normal file
View File

@ -0,0 +1,82 @@
# Use and Properly Configure Password Hashing
### One Paragraph Explainer
When storing user passwords, there are a few options to consider based on what the priority is. `Math.random()` should also never be used as part of any password or token generation due to its predictability.
All of the below algorithms/functions need to be implemented properly to provide any security. Please see the [IETF's recommendations](https://tools.ietf.org/id/draft-whited-kitten-password-storage-00.html#name-kdf-recommendations) for what parameters to use for each. You should use the recommended properties as a minimum, using higher parameters and a combination that's unique to your program can differentiate the hash of the exact same password and salt from someone elses implementation to yours, mitigating some of the risk if someone ever runs off with your password hashes.
The external dependency, `bcrypt` is the most widely supported and should be used when possible, as when using `bcrypt`, a number of 'rounds' can be specified in order to provide a secure hash. This sets the work factor or the number of 'rounds' the data is processed for, and more hashing rounds leads to more secure hash (although this at the cost of CPU time). The introduction of hashing rounds means that the brute force factor is significantly reduced, as password crackers are slowed down increasing the time required to generate one attempt.
The `scrypt` function included in the native crypto module can be used as it is a slight improvement over `bcrypt`, allowing for unlimited length passwords, and does not add a dependency, though it needs more configuration and is newer and thus less scrutinized. `scrypt` uses cost (to increase CPU/memory cost), blockSize (to increase memory cost), and parallelization (to increase the cost of breaking it up into separate operations) together to define how secure it is, how long it will take, and what it's most secure against.
If FIPS or other compliance is absolutely necessary, the older `PBKDF2` function included in the native crypto module should be used. `PBKDF2` has a similar api to `bcrypt` in that it uses an iteration count to define the strength and time to spend.
On track to be added sometime in 2021 (Through addition to OpenSSL) the `Argon2` function is the winner of the [Password Hashing Competition](https://password-hashing.net/) and top recommended by [OWASP](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md#modern-algorithms) and the [IETF](https://tools.ietf.org/id/draft-whited-kitten-password-storage-00.html#name-kdf-recommendations). Once added to the native crypto module, `Argon2` should be stable and take precedence.
### Code example - Bcrypt
```javascript
const iterations = 12;
try {
// asynchronously generate a secure password
const hash = await bcrypt.hash('myPassword', iterations);
// Store secure hash in user record
// compare a provided password input with saved hash
const match = await bcrypt.compare('somePassword', hash);
if (match) {
// Passwords match
} else {
// Passwords don't match
}
} catch {
logger.error('could not hash password.')
}
```
### Code example - SCrypt
```javascript
const outSize = 64;
const hash = scryptSync('myUnlimitedPassword','someUniqueUserValueForSalt',outSize).toString('hex');
// Store secure hash in user record
// compare a provided password input with saved hash
const match = hash === scryptSync('someUnlimitedPassword','derivedSalt',outSize).toString('hex');
if (match) {
// Passwords match
} else {
// Passwords don't match
}
```
### Code example - PBKDF2 (Password-Based Cryptography Specification Version 2.1)
```javascript
try {
const outSize = 64;
const digest = 'blake2b512';
const iterations = 12;
const hash = pbkdf2Sync('myPassword','someUniqueUserValueForSalt', iterations * 1000, digest, outSize).toString('hex');
// Store secure hash in user record
// compare a provided password input with saved hash
const match = hash === pbkdf2Sync('somePassword','derivedSalt', iterations * 1000, digest, outSize).toString('hex');
if (match) {
// Passwords match
} else {
// Passwords don't match
}
} catch {
logger.error('could not hash password.')
}
```
### What other bloggers say
From the blog by [Max McCarty](https://dzone.com/articles/nodejs-and-password-storage-with-bcrypt):
> ... it’s not just using the right hashing algorithm. I’ve talked extensively about how the right tool also includes the necessary ingredient of “time” as part of the password hashing algorithm and what it means for the attacker who’s trying to crack passwords through brute-force.
From the blog [Troy Hunt - Creator of HaveIBeenPwned.com](https://www.troyhunt.com/we-didnt-encrypt-your-password-we-hashed-it-heres-what-that-means/):
> Saying that passwords are “encrypted” over and over again doesn’t make it so. They’re bcrypt hashes so good job there, but the fact they’re suggesting everyone changes their password illustrates that even good hashing has its risks.