On 03/04/2015 08:59 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
The big difference between SRP and SCRAM is that if you eavesdrop
the SCRAM handshake, you can use that information to launch a
brute-force or dictionary attack. With SRP, you cannot do that. That
makes it relatively safe to use weak passwords with SRP, which is
not the case with SCRAM (nor MD5)
Thanks for the info!
Looking around a bit, one issue with SRP (as pointed out by Simon
Josefsson, the author of the SCRAM implementation for GNU SASL) is that
the username is included in the verifier (similar to our implementation
today with MD5) meaning that the stored data on the server is no longer
valid if the username is changed. Obviously, our users are used to
that, but it's still something to be considered.
Yes, good point, that's yet another thing that needs to be considered.
One question though- isn't the iteration option to SCRAM intended to
address the dictionary/brute force risk? SRP uses an exponentiation
instead of iterations but it's unclear to me if one is really strictly
better or worse than the other (nor have I found any discussion of that
comparison) for this vector.
Not sure what you mean. Yes, the iterations option in SCRAM is designed
to make brute forcing more expensive. For both a captured authentication
handshake, or if you steal a backup tape.
I'm not sure how expensive a brute force attack on SRP would be, using a
stolen backup tape. There doesn't seem to be an iterations count similar
to SCRAM. But note that SRP's resistance to brute-forcing the
authentication handshake is of a different kind. It's not just
expensive, but outright impossible. (Don't ask me how that works; I'm
not well-versed in the maths involved.) That's a big advantage because
it means that it's OK to use a fairly weak password like 'foobar123'
that would be trivially cracked with a dictionary attack. (You can still
connect to the server and try different passwords, but the server can
log that and throttle how many guesses / minute it let's you do)
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
