On Sat, 6 May 2000, Bruce Momjian wrote:
> > This'd take some rejiggering in (at least) CREATE USER and ALTER USER,
> > but it seems doable. I withdraw the complaint about portability...
>
> Yes, agreed. Doing it in the backend only is the way to go. We already
> have wire crypting.
>
> I think the only problem is moving dumps from on machine to another.
> The crypt version may not exist or be different on different machines.
>
> However, I now remember there was a bigger issue. I think the actual
> password has to be crypted based on the salt used supplied to the
> client. We can't do that based on the crypted version because we don't
> know the client can generate that version.
>
> Now, at the time, we were looking at Unix-style crypting of the
> password, which is one-way. This will not work. We need something that
> we can uncrypt in the backend before applying the client-supplied salt
> to see if the passwords match.
>
> 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.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from
$16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop
Superstore http://www.cloudninegifts.com
==========================================================================
