Re: Use of MD5 - Mailing list pgsql-bugs

Hi Jeffrey,

On 13.11.2013 09:40, Jeffrey Walton wrote:
> Might as well get this one out of the way....
>
> There's a lot of use of MD5 with mini-salts of 4 bytes. Its one
> thing if using MD5 as a PRF, but its another when using it for its
> security properties (or lack thereof). See, for example, crypt.c,
> user.c, and passwordcheck.c.
>
> varlena.c appears to claim MD5_HASH_LEN is 32 bytes rather than 16
> (perhaps its wishful thinking ?).

Heikki already responded to the MD5_HASH_LEN, so I'll try to comment on
the first paragraph.

Disclaimer: I'm not a security expert, so feel free to point out
inaccuracies and/or misconceptions ...

First, the central point here is crypt.c - the other two files are
merely interacting with it so have to follow the same approach.

Note that the password is actually hashed twice, once the username is
used as a salt, then the result is hashed with a 4B random salt specific
for a connection. This 4B salt is used in a challenge-response
authentication, so that the actual password hash (password hashed with
username as a salt) is not transferred over the network.

So attacking the system depends on whether the attacker can read the
locally stored password or not.


1) Attacker with a with local access

   Can read the password hash salted with just username. Well, I can't
   think of other salt usable in this scenario (the user needs to know
   it, so that he can connect by issuing just username+password).

   But is this vulnerable for sufficiently strong passwords? That is,
   reasonably long, nontrivial, non-dictionary, etc. I don't think so.


2) Attacker without local access / able to eavesdrop the authentication

   So the attacker can eavesdrop the 4B salt and the doubly-hashed
   password, and to attack the scheme needs to know either the original
   password, or the result of the first hashing (with username salt).

   Building a rainbow table only for the second phase is going to be
   difficult, because the passwords are 16B random strings (equivalent
   to ~20 character passwords using ASCII characters/numbers/symbols).
   So that's ~10e40 bytes, and thanks to the randomness it's impossible
   to build only portion of the table with common passwords etc. Not
   to mention there are 2^32 such rainbow tables possible.

   Building a rainbow table for both phases might work, but it has about
   the same issues as attacking the local acces - it's not going to work
   with reasonably strong passwords.


So, I see no particular vulnerability / weakness, here. If you're using
a weak password, no amount of hashing is going to help you in the end,
and I think it's predetermined to fail. Use strong secure passwords and
you're fine.

That being said, I think adding some more recent hashing algorithms
(say, Blowfish/SHA256/... which we already support in pgcrypto) would be
nice. Not necessarily to the second phase (hashed with the 4B salt), as
that would break the authentication with older clients, and attacking
16B random strings is hard even with MD5, but for the first phase.

regards
Tomas