On 21.07.2017 14:43, Adriano dos Santos Fernandes wrote:
On 21/07/2017 08:00, Alex via Firebird-devel wrote:
Mark, this is interesting. I know bcrypt is very used by nodejs/expess
people and I even used it myself.
But what is more interesting, isn't Firebird still using these "not
suitable for passwords" hashes in recent versions?
AFAIK it uses SHA1 with per user SALT.
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.
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".
If we talk about stolen security database and passwords brute forcing -
SRP + SHA1 hashes are weak if passwords are short. If password is random
20 bytes sequence brute force attack requires unreal computational
resources. (This was discussed with Jim here or may be in architect a
few years ago). Use of computational-heavy hash can make SRP better but
it's not as efficient as use of long password (linear vs exponential
dependency). As an additional problem with this approach let's not
forget DoS attacks - it's much simpler to DoS a system that needs a lot
of resources for initial login validation, just run a lot of fake logins
to it.
The only 'small' problem with long passwords is that people do not want
to remember & type random 20 bytes sequence as password. This can be
solved as follows. Minimum length of user password should be limited,
but something typical for today (like 10 bytes containing letters &
digits & punctuation) should be enough. Real password for SRP is a
random bytes' sequence, short password from the client is used as an
encryption key for any computational-heavy crypt (not hash!) algorithm,
used to encrypt that random sequence. When setting password for a user
this random bytes' sequence is used as a password for SRP and also
stored in an encrypted form in that same security database. When user
logins with short password encrypted random sequence appropriate for
passed login is retuned to the client which must decrypt it himself.
This helps to solve DoS attack problem - heavy computational algorithm
is run by client, not server. Client decrypts initial random sequence
and uses it for normal SRP authentication.
This authentication can be added as plugin to any FB versions starting
with 3, no changes in basic soft is needed.
------------------------------------------------------------------------------
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
