Re: You're on SecurityFocus.com for the cleartext passwords.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Vince Vielhaber <vev(at)michvhf(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, "Sverre H(dot) Huseby" <sverrehu(at)online(dot)no>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: You're on SecurityFocus.com for the cleartext passwords.
Date: 2000-05-06 15:17:52
Message-ID: 200005061517.LAA10084@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> > The goal here was to make wire sniffing unproductive, and because the
> > server supplied the salt to be used by the client, you can't just
> > re-use a sniffed password you saw on the wire.
> >
> > At least this is my recollection of the problem.
> >
> >
>
> We can do it with MD5. Sverre has offered up a java version of it
> that he wrote, I can convert it to C and make sure it at least runs
> on FreeBSD, IRIX, DOS/Windows, and HPUX 8-10. If it runs in unix then
> it should also run in OS/2. If we roll our own we should be safe. I
> can even include a simple test to make sure it works for all platforms
> we support.

Yes, I seem to remember that was the issue. If we only did crypting on
the server, and allowed passwords to come cleartext from clients, then
we only needed crypting on the server. If we crypt in a one-way fashion
on the client before coming to the server using a random salt, we have
to do the other part of the crypting on the client too.

In other words, it is the one-way nature of the password crypt we used
on the client that caused us to need the _exact_ same input string to
go into that crypt on the client and server, so we would need the same
crypt process in both places.

Now, let me ask another, better question:

Right now the password receives a random salt from the server, it uses
that salt to crypt the password, then send that back for comparison with
the clear-text password we store in the system.

What if we:
store the password in pg_shadow like a unix-style password with salt
pass the random salt and the salt from pg_shadow to the client
client crypts the password twice through the routine:
once using the pg_shadow salt
another time using the random salt

and passes that back to the server. The server can use the pg_shadow
copy of the password, use the random salt make a new version, and
compare the result.

This has the huge advantage of not requiring any new crypting methods on
the client. It only requires the crypt to happen twice using two
different salts.

Sounds like a winner. Comments?

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vince Vielhaber 2000-05-06 15:38:03 Re: You're on SecurityFocus.com for the cleartext passwords.
Previous Message Vince Vielhaber 2000-05-06 14:53:25 Re: You're on SecurityFocus.com for the cleartext passwords.

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2000-05-06 15:38:03 Re: You're on SecurityFocus.com for the cleartext passwords.
Previous Message Vince Vielhaber 2000-05-06 14:53:25 Re: You're on SecurityFocus.com for the cleartext passwords.