View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
5899 | Composr | core | public | 2024-08-20 00:46 | 2024-08-21 18:12 |
Reporter | PDStig | Assigned To | PDStig | ||
Priority | normal | Severity | feature | ||
Status | resolved | Resolution | fixed | ||
Product Version | 11.beta1 | ||||
Summary | 5899: Remove all uses of md5 in crypt and increase general crypt security | ||||
Description | md5 hashing is not secure, and using it in any cryptographic processes defeats the purpose of bcrypt security. Make the following changes in v11: a) ratchet_hash should not md5 the password prior to hashing; it should hash the raw password and salt combination. My research into this indicated using md5 decreases the security of bcrypt due to the collisions and vulnerabilities with md5 (e.g. it is possible for multiple passwords to have the same md5... thus using it made our password system no more secure than using salted md5 hashes directly). b) ratchet_hash_verify needs to also be updated accordingly. We need a new compat_scheme, 'bcrypt' (and bcrypt_temporary / bcrypt_expired), for v11, so this function can use the legacy methods for v10 hashed passwords. c) Increase the security of salts; use 32-byte base64 strings from now on (using the updated get_secure_random_string which also no longer uses md5). Do the same for login cookies (but they might need to be URL-safe / base32). d) Every change of password should also change the member's salt. This mitigates rainbow table attacks. Sure, bcrypt has its own internal salting. But if we do not change the member's salt on every password change, the extra security of it is lost. e) f_password_history should generate its own salt and a new ratchet_hash so it does not match what is in f_members for security reasons. f) When a member logs in and has a v10 hashed password, re-hash it with the new v11 method and salts automatically. g) Make site salts more secure by using a full pseudo md5 hash (but not the md5 function, rather generate every character cryptographically byte by byte). Don't change current site salts because too many things are hashed with it which will cause massive breaks. h) Increase the general security of the site by using base32 (URL-safe) strings for tokens, sessions, etc instead of the current base16. | ||||
Tags | Roadmap: v11, Type: Security | ||||
Attach Tags | |||||
Time estimation (hours) | |||||
Sponsorship open | |||||
Date Modified | Username | Field | Change |
---|---|---|---|
2024-08-20 00:46 | PDStig | New Issue | |
2024-08-20 00:46 | PDStig | Status | Not Assigned => Assigned |
2024-08-20 00:46 | PDStig | Assigned To | => user4172 |
2024-08-20 00:47 | PDStig | Tag Attached: Type: Security | |
2024-08-20 00:47 | PDStig | Tag Attached: Roadmap: v11 | |
2024-08-20 00:56 | PDStig | Note Added: 0009247 | |
2024-08-20 00:58 | PDStig | Note Edited: 0009247 | |
2024-08-21 18:12 | PDStig | Status | Assigned => Resolved |
2024-08-21 18:12 | PDStig | Resolution | open => fixed |