Update Password Storage Cheat Sheet: Clarify scrypt parameters and wording improvements #1750
Conversation
…rding improvements
Prasad-JB
requested review from
kwwall,
mackowski,
jmanico and
szh
as code owners
|
Hello! Just a gentle reminder about this PR — it clarifies scrypt parameters to reduce confusion between CPU and memory cost. Please let me know if you’d like any changes or additional explanations. Thanks for your time! |
|
This may take time to approve, all password cheatsheet changes must be approved by @Sc00bz first :) Please give him time! :) |
| - N=2^13 (8 MiB), r=8 (1024 bytes), p=10 | ||
|
|
||
| These configuration settings provide an equal level of defense. The only difference is a trade off between CPU and RAM usage. | ||
| These configuration settings provide a minimal level of defense. The only difference is a trade off between CPU and RAM usage. |
There was a problem hiding this comment.
I would say "a minimal and an equal" since both are true
There was a problem hiding this comment.
Thanks for the suggestion! I can update the phrasing to “a minimal and an equal level of defense” if that works.
|
|
||
| Remember that once your password hashing method is selected, it will have to be upgraded in the future, so ensure that upgrading your hashing algorithm is as easy as possible. During the transition period, allow for a mix of old and new hashing algorithms. Using a mix of hashing algorithms is easier if the password hashing algorithm and work factor are stored with the password using a standard format, for example, the [modular PHC string format](https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md). | ||
|
|
||
| ### International Characters |
There was a problem hiding this comment.
why we are removing this?
There was a problem hiding this comment.
Thanks for the feedback. I’ll make sure to keep the guidance about upgrading hashing algorithms and supporting a mix of old and new hashes intact. I’ll also update the phrasing to “a minimal and an equal level of defense” as suggested.
|
Thanks everyone for the reviews, All suggested fixes have been applied. |
| - **Use [Argon2id](#argon2id) with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism.** | ||
| - **If [Argon2id](#argon2id) is not available, use [scrypt](#scrypt) with a minimum CPU/memory cost parameter of (2^17), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1.** | ||
| - **Use [argon2id](#argon2id) with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism.** | ||
| - **If [scrypt](#scrypt) is not available, use [scrypt](#scrypt) with a minimum CPU/memory cost parameter of (2^17), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1.** | ||
| - **For legacy systems using [bcrypt](#bcrypt), use a work factor of 10 or more and with a password limit of 72 bytes.** | ||
| - **If FIPS-140 compliance is required, use [PBKDF2](#pbkdf2) with a work factor of 600,000 or more and set with an internal hash function of HMAC-SHA-256.** | ||
| - **If FIPS-140 compliance is required, use [pbkdf2](#pbkdf2) with a work factor of 600000 or more and set with an internal hash function of HMAC-SHA-256.** |
There was a problem hiding this comment.
What's the reason for removing capitalization and removing the comma in the number 600,000? It makes it much easier to read IMHO
This PR improves the Password Storage Cheat Sheet by updating the wording around the scrypt parameters to reduce confusion between CPU cost and memory cost. Specifically, it:
Clarifies the correct description of scrypt’s parameters (N, r, p) to better reflect their roles.
Suggests improved phrasing to accurately represent the trade-offs between CPU and RAM usage.
Fixes minor wording issues for better readability and accuracy in lines 118 and 126 of Password_Storage_Cheat_Sheet.md.
These changes aim to enhance the clarity and precision of the cheat sheet, helping readers better understand password hashing configurations.