Thread: Insecurity in MD5 authentication (again)
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 |
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
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, Pennsylvania19073