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