Re: 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 daemonsThe stunnel program is designed to work  as  SSL
encryptionwrapperbetween remote client and local (inetd-startable) orremote server. The concept is that having non-SSL
awaredaemonsrunning  on  your  system you can easily setup them tocommunicate with clients over secure SSL
channel..stunnelcan be used to add  SSL  functionality  to  commonlyused  inetd  daemons  like  POP-2,  POP-3  and
IMAPserverswithout any changes in the programs' code.
 

-- 
greg