doc: Adding best practises for crypto.pbkdf2 #3290
Conversation
|
The change regarding salts is a tad misleading. For each encrypted string, yes, you should create a new salt, but you need to preserve that salt for decryption. Granted someone who doesn't know that shouldn't really be using this function. |
| higher the number, the more secure it will be, but will take a longer amount of | ||
| time to complete. | ||
|
|
||
| Chosen salts should also be unique and random (ideally using crypto.randomBytes) |
There was a problem hiding this comment.
It'd be great if crypto.randomBytes could be linked to the documentation for the function.
|
LGTM |
Hey @jasnell, rebased and updated, also with a link as @brendanashworth suggested. |
|
@jasnell Very sorry for my late reply. I missed this. @tomgco I have one question and one comment on the description in regarding salt.
IIRC, in PBKDF2 the salt is put into HMAC with the number of iteration counter so that its length is not necessary to match the length of the digest function. As in the example, the length of salt is 4. Of course, the longer is the better. Do you have any reason for matching with it?
Reading section 4 of RFC2818, https://tools.ietf.org/html/rfc2898#section-4 , and A.2.1 of NIST 800-132 , http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf , there is a use case to add a non-random octet to a salt according to its purpose. So the description above is not always the case. I think we need not to write a whole description as the same of that in the references above and it is enough to write a pointer to them with a short comment. Description in regarding iteration is good. At first, I thought the iteration number of 100,000 in the example seems to be so large, but I found that it took only 1.6 sec on my host so it is no problem. |
No I didn't, thanks for the ping.
I use it as a general rule of thumb, based on the strength ( and the final computed result ) of the hash function (from SHA-256 onwards), A publication that NIST released in 2010 recommended the minimum salt length be 128bits, so to recommend the length of the digest function exceeds the recommended values and grows with the introduction of longer hash-functions.
Although that is true, the complexity that would be needed to be put into the documentation would possible make it more difficult and scarier for a developer who is less security minded, but wants to use sensible defaults. And I could argue that if someone needed to implement an octect to signify the use case then this would fall outside of what should be in the documentation; for me, if we was to introduce that, it would be the same as describing the algorithm behind PBKDF2. However you make a good point that maybe we could add the RFC as a link, and encourage the users of node to read through it to understand each parameters in more detail?
Maybe we should make a note also around how the longer the function takes the more desirable it is, as it becomes much harder for an attacker. Thanks for the feedback, Let me know if you would like me to incorporate anything that I have mentioned in this message in the PR, Thanks 👯 |
|
@tomgco I agree the doc should not be too complex. I also think its correctness is important because it is not only for novices but also for experts. For simplicity, it is not necessary to add the description of a use case of a purpose prefix in the salt. Let it to the reference. |
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512.
Brilliant, I agree, thanks. I have updated the PR accordingly, and believe we are all in agreement with the changes? |
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
|
Yes, thanks for revising. Landed in d16def5 with adding an external link to the NIST reference. Thanks for your collaboration again. |
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Added some information around usages of how to use iterations, how to choose decent salts and updating the example to have a significant work factor and to use sha512. PR-URL: #3290 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Shigeki Ohtsu <[email protected]>
Added some information around usages of how to use iterations, how to
choose decent salts and updating the example to have a significant work
factor and to use sha512.