Replies: 3 comments
-
Hi Ethin, You have some control over the passwords in your password files, in particular you can use PBKDF2 on Windows and macOS. See:
Did you reach this conclusion based on the paragraph above? Thanks, |
Beta Was this translation helpful? Give feedback.
-
@bernardnormier The conclusion was drawn from the fact that PBKDF2 is (only) supported on Windows and MacOS, as you stated, but the manual is quite clear on the password hash algorithms available to non-windows/non-MacOS platforms:
(Sourced from the page you linked.) It might be simpler (and better) to replace PBKDF2 entirely with Argon2, and just universally use that; Argon2 has a password format of its own that all implementations use, so people don't have to worry about the platform they're using potentially controlling security properties like this. It is well understood in cybersecurity circles that it is bad practice to use a hash function for password storage when the hash function in question was not designed for storing passwords in the first place. Crypt with SHA-256/512 isn't much more secure than just using SHA 256/512 alone, and it's still open to brute-force attacks because it isn't a memory-hard hash function. |
Beta Was this translation helpful? Give feedback.
-
I should note that I'm just following OWASP recommendations here. The saulting of passwords with crypt does make it harder to brute-force, and much more difficult to build rainbow tables. But it's still possible to dramatically speed up the computation via dedicated hardware/GPUs, although gPUs won't be all that comfortable with SHA-512's 64-bit operations. Memory hard hash functions are recommended though if only because they're designed to (attempt) to completely eliminate a GPU or dedicated hardware from the equation, making it far, far more difficult to crack the password, regardless of how complex it is, as long as the parameters are set correctly. Source: https://security.stackexchange.com/questions/39450/sha-512-unix-passwords-how-secure-are-those-hashes-really |
Beta Was this translation helpful? Give feedback.
-
As it currently stands, the password hashing algorithm used by Glacier2 is insecure and does not follow security best practices or OWASP recommendations. In decreasing order of preference, the following algorithms are currently recommended:
This information, and their associated parameters, were sourced from the OWASP Password Storage Cheat Sheet as of 2023-04-06.
PBKDF2 is trivially implementable via a library like fastpbkdf2: the library is licensed under CC0 and, although it relies on OpenSSL's hash functions, it would most likely be easy to modify it to use something like sphlib's implementations so that it's portable. Or we can simply use the platform's provided cryptographic interfaces where available, or fall back to OpenSSL/LibreSSL where unavailable or where that's the default, since ICE already uses that.
As for Argon2, that could potentially pose a problem. Again, we could either try to find a CC0 implementation, or we could use OpenSSLs (this might be simpler, given that we already use it). Either way, I thought I would propose this since I'd like to Ice be a very secure platform for which people can build things upon, and and it uses weak password hashing algorithms right now (at least, according to the manual). This might be something that would have to wait for a new major release, however.
Beta Was this translation helpful? Give feedback.
All reactions