-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: correct pbkdf2 salt length recommendation #17524
Conversation
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, although it raises some questions:
- Longer salts don't really affect PBKDF2's performance so why stop at at 16 bytes?
- Shorter salts don't affect PBKDF2's security properties so why stop at 16 bytes?
(The salt thwarts precomputed dictionary attacks; even a two-byte salt goes a long way towards mitigating that.)
Regardless of my understanding of the implications below, NIST is a reasonable reference and it should not be up to us to make any security recommendations.
This is a minimum recommendation so longer values are always permitted, but as salts need to be stored along with their hash values, it would be inefficient to store needlessly long salts.
Shorter salts are suited to prevent dictionary attacks, but PBKDF2 can also be used to reduce the chance of key reuse, which heavily relies on the salt length. For example, 100 operations using the same password and a two-byte salt would have a collision probability of 7%, and after 400 more operations, there is an 85% chance of having reused the same key. |
Oh, I'm not disagreeing but if you look at e.g. OWASP's recommendations, it says to use a 32 byte or even 64 byte salt. (And if you look elsewhere, you can find recommendations of as little as 4 or 8 bytes. So many options to chose from...) |
I guess the question here is what we personally feel like what is right to recommend. So do we want to have the current recommendation to be the same as NIST or recommend a higher value as currently? |
As long as we reference the NIST SP, this pull request is correct, so I am going to go ahead and land this. Apart from that, we should not make any quantitative security recommendations apart from those specified by appropriate institutions, unless they are specific to node. As @bnoordhuis pointed out, other recommendations suggest using different salt lengths, which is a fact we could mention at this point as part of the documentation. |
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: nodejs#17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Landed in 560c182, thank you for your first contribution! 🎉 |
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
According to the linked document: "The length of the randomly-generated portion of the salt shall be at least 128 bits." [NIST SP 800-132] PR-URL: #17524 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Corrects the recommended salt length recommendation in the documentation for
crypto.pbkdf2
andcrypto.pbkdf2Sync
.Checklist
Affected core subsystem(s)
doc