On 21-7-2017 21:55, Leyne, Sean wrote:
I think the point is, if a cracker has a security database, it can run
billions of SHA1 hashes per second using the same salt in a brute
force attack, because SHA1 is a fast (suitable to hash large files) algorithm.
With bcrypt, with is purposely slow, the cracker can't do a brute
force attack so easily.
That's another issue, different from the one actively discussed last time
when 2 different documents have same SHA1 hash, which is often correctly
mentioned as "SHA1 weakness".
I agree that HASH() and ENCRYPT() are completely different problems.
Let's not "pollute" this thread with discussions about the complete
unsuitability of HASH() for password handling.
We can't control that a developer might not realize that HASH() <> ENCRYPT().
I started this branch of the discussion because I think we should be
very clear in our documentation that this proposal for the extension of
hash with cryptographic hashing algorithms is **not suitable for
password hashing**, but only for hashing data for authenticity or easy
'identity' comparisons.
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
