Thread: md5 hash question (2)

sorry, but I have another q about that md5 hashing. When I use a sniffer on the wire I see md5 hashes of user -
probablythe password hash. But when I compare the password hash with the hash on the wire I see they are different. In
whatformat is the md5 hash on the wire encoded? I've tried double md5'ing but didn't get the right hash. 

Regards,
Cagil.
-----------------

Çagil Seker <cagils@biznet.com.tr> wrote:
> sorry, but I have another q about that md5 hashing. When I use a
> sniffer on the wire I see md5 hashes of user - probably the password
> hash. But when I compare the password hash with the hash on the wire
> I see they are different. In what format is the md5 hash on the wire
> encoded? I've tried double md5'ing but didn't get the right hash.
>

There seems to be some confusion regarding the md5 authentication method
used in postgresql, and i thought it might be good if i typed this
message so that it can be referred to if anyone asks these questions
again.

Someone will surely correct me if i'm wrong :)

The password in the database is stored like this:

md5passwd = "md5"+md5(cleartxtpasswd+user);

When connecting and authenticating  this happens:

The server generates a random salt  (nonce) and sends it to the client.

md5salt = 4 random chars

The client then does this:

md5hash = md5(md5(cleartxtpasswd+user)+md5salt)

and sends it to the server.

The server then does the same on it's side and compares the result with
the hash gotten from the client. If they match the password is correct.

This is standard MAC / shared secret stuff.

It's done do avoid sending clear text passwords (or even the stored md5
password, to prevent brute force cracking) over the wire.

Regards
Magnus

"Magnus Naeslund(f)" <mag@fbab.net> writes:
> [ good summary ]

> md5hash = md5(md5(cleartxtpasswd+user)+md5salt)

> This is standard MAC / shared secret stuff.
> It's done do avoid sending clear text passwords (or even the stored md5
> password, to prevent brute force cracking) over the wire.

It might help to be a little more clear about the reasons for doing it
this way:

1. Including the username into the stored-password calculation is done
to make it unobvious if two users have chosen the same password.

2. Using a random salt in the challenge/response protocol is done to
prevent replay attacks (ie, even if an attacker has sniffed your
previous sessions and seen what you sent over the wire, it's unlikely to
help him log in himself; he'd need to be lucky enough to be challenged
with the same random salt as he'd seen used before.)

One thing this setup does *not* do is prevent an attacker who's seen the
contents of pg_shadow from logging in.  He'd need to make a modified
client-side library so that he could inject md5(cleartxtpasswd+user)
directly into the middle of the calculation, but he could do that and
the server would be none the wiser.  We consider this not a fatal
problem, because anyone who's been able to read pg_shadow is already
superuser in some guise, and hardly has need to steal any more database
passwords.  It would be better if it weren't true, but we didn't see any
way to prevent that without either making the protocol vulnerable to
sniffing, or requiring true reversible crypto and not just a crypto hash
(which would create all sorts of export issues, at least for those of
us in the US).

            regards, tom lane

�a��l �eker wrote:
>
> sorry, but I have another q about that md5 hashing. When I use
> a sniffer on the wire I see md5 hashes of user - probably the
> password hash. But when I compare the password hash with the
> hash on the wire I see they are different. In what format is
> the md5 hash on the wire encoded? I've tried double md5'ing but
> didn't get the right hash.

Ah, so your are snooping.  The trick is that a random number is sent to
the client on connection.  The client double-MD5 encrypts the
user-supplied password --- once using the username as salt, and secondly
using the random number sent by the server.  That way, you can't replay
the sniffed password later to connect to the server.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073