On 2017-07-19 13:00, Adriano dos Santos Fernandes wrote:
On 19/07/2017 05:27, Dimitry Sibiryakov wrote:
19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
They will store hash on field of appropriate length for the given
hash
and index it.
On contrary, there is no point to store hash value if its purpose is
to speed up lookup only.
I hope you don't need to recreate your index and recompute whole table
hashes with a slow algorithm.
In most cases original string (password) is not even stored and hashes
are used to check if a password matches a previously one.
The proposed hashes are **not** suitable for passwords; you shouldn't
use a pure cryptographic hash for passwords as they are optimized for
speed. For passwords you need to use an algorithm with a work
factor/iteration count (eg pbkdf2, bcrypt) that slows it down.
The work factor is a protection against brute forcing and timing based
attacks. When you verify those hashes, you first retrieve the stored
hash and then you verify the password by hashing it with the same
parameters (work factor + salt) and then compare the hash. To avoid
revealing non-existence, if a password does not exist (user not found),
the comparison is done using the current default work factor + a random
salt + an empty/random hash of the right length.
So adding cryptographic hashes good, but do not assume they can be used
for passwords.
Mark
------------------------------------------------------------------------------
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
