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(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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073