Thread: md5 auth procotol - can it be replayed?

How the md5 hashed authentication method works? Is it protected against
replay attacks? Here is what I have in mind:

* If the server stores salted hashed passwords, then I do not see how
the server could authenticate the users without getting the password in
clear text?
* If the server stores (unsalted) password hash values, then basically
there is almost no difference between a clear text password and an md5
hash, because anyone can replay the send the same hash value and log in
again.

Am I missing something?

Thanks,

   Laszlo

Greetings,

* Nagy László Zsolt (gandalf@shopzeus.com) wrote:
> How the md5 hashed authentication method works? Is it protected against
> replay attacks? Here is what I have in mind:
>
> * If the server stores salted hashed passwords, then I do not see how
> the server could authenticate the users without getting the password in
> clear text?

If you're interested in how these things can be addressed, you should
review the SCRAM protocol.

> * If the server stores (unsalted) password hash values, then basically
> there is almost no difference between a clear text password and an md5
> hash, because anyone can replay the send the same hash value and log in
> again.

If the hash was sent in the clear, then that would be true, but it
isn't.

> Am I missing something?

There is a challenge/response compoent, so the md5 hash which is stored
is not what is sent across the wire.  That prevents replay attacks when
the attacker is simply sniffing the network.  If the attacker is able to
acquire the as-stored hash then, yes, that can be used to authenticate.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Nagy L�szl� Zsolt (gandalf@shopzeus.com) wrote:
>> Am I missing something?

> There is a challenge/response compoent, so the md5 hash which is stored
> is not what is sent across the wire.  That prevents replay attacks when
> the attacker is simply sniffing the network.

Worth noting here is that the challenge key space is not all that huge,
so an attacker who captures a large number of challenge/response pairs
would have a good probability of being able to answer the next challenge
successfully.  However, if you're concerned about sniffing of your
database connections happening on that scale, you really ought to be using
SSL encryption which would make the whole thing moot.  In many cases,
capturing a database session would reveal lots of interesting data passing
over the wire whether or not you'd captured a usable password --- so I'd
call it fairly irresponsible to not be using SSL if you think your
connection is open to sniffing.

            regards, tom lane

>> There is a challenge/response compoent, so the md5 hash which is stored
>> is not what is sent across the wire.  That prevents replay attacks when
>> the attacker is simply sniffing the network.
> Worth noting here is that the challenge key space is not all that huge,
> so an attacker who captures a large number of challenge/response pairs
> would have a good probability of being able to answer the next challenge
> successfully.  However, if you're concerned about sniffing of your
> database connections happening on that scale, you really ought to be using
> SSL encryption which would make the whole thing moot.  In many cases,
> capturing a database session would reveal lots of interesting data passing
> over the wire whether or not you'd captured a usable password --- so I'd
> call it fairly irresponsible to not be using SSL if you think your
> connection is open to sniffing.
Thank you for your responses, this is exactly what I was looking for.