On 03/04/2015 06:11 PM, Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost <sfr...@snowman.net> wrote:
No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-server side certificates and straight password-based auth
(which is clearly why it was invented in the first place) and so, yes,
md5 would still have to be kept around, but we'd at least be able to
deprecate it and tell people "Use TLS-SRP if you really want to useou
passwords and care about network security".
SCRAM doesn't actually fix the issue with network connection hijacking
or eavesdropping, except to the extent that it protects the password
itself, and so we might want to recommend, for people who are worried
about network-based attacks, using TLS-SRP.
Assuming we do implement SCRAM, what does TLS-SRP give us that we wouldn't
get by just using SCRAM over a TLS connection?
Good question and I'll have to dig more into that. SCRAM does appear to
support channel binding with TLS and therefore there might not be much
to be gained from having both.
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)
Let me list the possible attacks that we're trying to protect against:
A) Eve eavesdrops on the authentication exchange. Can she use the
information gathered directly to authenticate to the server?
B) Can Eve use the information to launch a dictionary or brute force the
password?
C) Can a malicious server impersonate the real server? (i.e. does the
protocol not authenticate the server to the client)
D) If Eve obtains a copy pg_authid (e.g from a backup tape), can she use
that information to authenticate directly? (Brute forcing the passwords
is always possible in this case)
A) B) C) D)
password Yes Yes Yes No [1]
MD5 No Yes Yes Yes
SCRAM No Yes No No
SRP No No No No
[1] assuming that pg_authid stored MD5 hashes, not plaintext passwords,
which should be the case these days.
Note that this table does not consider how difficult a brute-force
attack is in each case; MD5 is a lot cheaper to calculate than SCRAM or
SRP hashes. And there are more things to consider like implementation
effort, strength of the underlying hash and other algorithms etc.
Also, attacks A), B) and C) can be thwarted by using SSL, with the
client configured to check the server certificate (sslmode=verify-full).
So actually, password authentication with SSL is not a bad option at
all; it's actually better than MD5 because it doesn't allow attack D).
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
