I'm sorry to bring this up again. From the archives I found that the 
current md5 authentication scheme of postgres was designed in 2001. I 
found a debate about it's security from 2002.
http://archives.postgresql.org/pgsql-hackers/2001-06/msg00511.php
http://archives.postgresql.org/pgsql-hackers/2001-06/msg00952.php
http://archives.postgresql.org/pgsql-general/2002-06/msg00484.php

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.

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.

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

I realize this would require changes on both the client and server side, 
but it would up the security of the authentication mechanism one notch.

Please Cc me in any replies, since I am not on this list.

-- 
Richard van den Berg, CISSP

Trust Factory B.V.      | http://www.trust-factory.com/
Bazarstraat 44a         | Phone: +31 70 3620684
NL-2518AK The Hague     | Fax  : +31 70 3603009
The Netherlands         |

Thu, 26 Aug 2004 13:48:00 +0200
Richard van den Berg <richard.vandenberg@trust-factory.com>
Insecurity in MD5 authentication (again)
Richard van den Berg <richard.vandenberg@trust-factory.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


29 Aug 2004 16:33:10 -0400
Greg Stark <gsstark@mit.edu>
Re: Insecurity in MD5 authentication (again)

This seems to have shown two problems.  First is using the constant
username 'postgres' for postgres login salt, but if we use something
variable we would have to pass that constant on the wire so everyone
will see it.  We can't encrypt the random salt with the password because
the server doesn't know the password.  We could have the password be
different from the username so the possible hashes couldn't be
precomputed until you saw the first passing of the salt, but that
doesn't seem to buy us much.

The second problem is the possible reuse of random salt by listening to
a lot of connections.  Greg, where do you get the 64k connections number
as the probability of a duplicate using the birthday problem?  I don't
seems to have any tools that can compute values that large in a
reasonable time.

---------------------------------------------------------------------------

Greg Stark wrote:
> Richard van den Berg <richard.vandenberg@trust-factory.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
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
  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

Thu, 7 Oct 2004 13:28:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Insecurity in MD5 authentication (again)