Skip site navigation (1) Skip section navigation (2)

Re: Insecurity in MD5 authentication (again)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Insecurity in MD5 authentication (again)
Date: 2004-08-29 20:33:10
Message-ID: 87wtzhk7ll.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Richard van den Berg <richard(dot)vandenberg(at)trust-factory(dot)com> writes:

> My problem is this: we have ODBC users working from home, so they cannot use
> SSL unless we buy the commercial drivers. We decided that encrypting the data
> is not required, but we do need to strictly protect access to our database.

You could always use an SSL proxy behind the ODBC driver's back.

> With the current MD5 authentication, an eavesdropper can obtain the random
> salt and matching MD5 response. When enough logins are eavesdropped on, it
> becomes feasible for the eavesdropper to connect to the server until a salt is
> offered for which it knows the valid MD5 response.


Well the salt is 32 bits, so you would expect someone to have to eavesdrop
about 64,000 connections before they're likely to see a birthday attack
collision. That's a lot of connections. Put another way, after eavesdropping
64,000 connections then they would be able to find a matching salt in their
database once every 64,000 connection attempts. (The randomness used for the
salt leaves a bit to be desired, but exploiting that would take some effort.)

However, you should realize that without something like SSL someone able to do
an active attack can hijack the TCP connection *after* the connection is made.
I'm not sure what kind of eavesdropper you're afraid of, but anyone capable of
sniffing the traffic is likely going to be able to inject their own packets
and take over an existing connection.

[Incidentally, in investigating the size of the md5 salt I noticed this
incorrect comment in src/backend/postmaster/postmaster.c. Nibbles are not 16
bits.


--- postmaster.c.~1.419~	2004-08-04 16:09:47.000000000 -0400
+++ postmaster.c	2004-08-29 16:14:41.000000000 -0400
@@ -1176,9 +1176,11 @@
 				gettimeofday(&later, &tz);
 
 				/*
-				 * We are not sure how much precision is in tv_usec, so we
-				 * swap the nibbles of 'later' and XOR them with 'earlier'. On
-				 * the off chance that the result is 0, we loop until it isn't.
+				 * We are not sure how much precision is in
+				 * tv_usec, so we swap the high and low 16 bits
+				 * of 'later' and XOR them with 'earlier'. On
+				 * the off chance that the result is 0, we loop
+				 * until it isn't.
 				 */
 				random_seed = earlier.tv_usec ^
 					((later.tv_usec << 16) |


]

> To prevent this attack, the salt should be communicated using a Diffie-Hellman
> key exchange. This way, the salt will be known by the server and the client,
> but not by an eavesdropper. See
> http://www.rsasecurity.com/rsalabs/node.asp?id=2248


If you have any concern at all about the network layer that you're
communicating over I think it's a no-brainer to go straight for SSL. Pretty
much the only time I would suggest using a non-encrypted connection would be
over a local area network in a physically secure location. (Something that
describes a lot of uses.) Even then encrypting could be justified on the basis
of reducing the impact of an intrusion.

If your database driver doesn't support it then tunnel over an SSL or SSH
proxy. For Unix you could just use something like stunnel. I'm not familiar of
software for Windows to do it but I would expect it would exist.

From the debian package:

Package: stunnel
Description: Universal SSL tunnel for network daemons
 The stunnel program is designed to work  as  SSL  encryption
 wrapper between remote client and local (inetd-startable) or
 remote server. The concept is that having non-SSL aware daemons
 running  on  your  system you can easily setup them to
 communicate with clients over secure SSL channel.
 .
 stunnel can be used to add  SSL  functionality  to  commonly
 used  inetd  daemons  like  POP-2,  POP-3  and  IMAP servers
 without any changes in the programs' code.

-- 
greg


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-08-29 21:08:48
Subject: pgsql-server: Add WAL logging for CREATE/DROP DATABASE and CREATE/DROP
Previous:From: Tom LaneDate: 2004-08-29 19:27:32
Subject: Re: beta 1 failed on linux mipsel

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group