On 21-7-2017 13:00, Alex via Firebird-devel wrote:
Yes, but SHA1 weakness becomes important only when password becomes as long as hash, i.e. 20 bytes for sha1. Without enforcing users to have long passwords replacing hash makes no sense.
That is unfortunately not true. The weakness that allows one to produce a collision is not relevant here. The problem is purely one of speed. Plain SHA1 used for passwords are now 'trivially' bruteforced using GPUs (trivial compared to other algorithms, and especially for shorter passwords).
Eg see https://www.troyhunt.com/our-password-hashing-has-no-clothes/ (from 2012), a single GPU could try 2.2 billion hashes per second. And he demonstrates that from a sample of 40000 passwords hashed using SHA-1 + salt he can easily crack 63% of them within 44 minutes, and that was 5 years ago.
The consensus in the security industry is that plain SHA1 (or any plain cryptographic hashing algorithm) even with salt is not suitable for passwords, and that an algorithm like PBKDF2, bcrypt, scrypt, etc should be used. See also https://patrickmn.com/security/storing-passwords-securely/
However if I recall the discussion about SRP, SRP doesn't actually store the hash of the password itself, but calculates a sort of public / private key that can be used in an authentication challenge to see if the user used the original password for authentication. I'm not sure about the strengths or weaknesses of that.
Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
