Re: [HACKERS] Updated TODO list

I agree with Gene. Following this discussion, I sense a reluctance to
implement stronger password schemes because of the extra development
hassles (compatibility, crypto prohibitions, maintenance).

1) Divide and conquer: the developers are concerned about both "over the
wire" and server passwords. I suggest you focus on the server side and
leave the over the wire security to the DB admin/sys.admin as an
installation issue. If they choose to use SSL, SSH, IPsec or a home-grown
authentication handshake, that's of no concern to pgsql. Just think of it
as a telnet session into the server.

2) On the server side, use the native crypt(3) by default (or the NT
equivalent) and store the password hash. The strength of the crypt will
vary depending on the installation, but that's really up to the choice of
OS and installation. If someone wants to patch for PAM, Kerberos or
whatever, that's fine too, as long as you can always revert back to the
plain old crypt(3).

Ciao--Louis  <louis@bertrandtech.on.ca> 

Louis Bertrand       http://www.bertrandtech.on.ca
Bertrand Technical Services, Bowmanville, ON, Canada  

OpenBSD: Secure by default.  http://www.openbsd.org/

On Thu, 15 Jul 1999, Gene Sokolov wrote:

> From: Bruce Momjian <maillist@candle.pha.pa.us>
> > > > Doing the random salt over the wire would still be a problem.
> > >
> > > There is absolutely no technical problem with storing hashed passwords
> and
> > > still sending salted hash over the wire. It was recently discussed in
> detail
> > > in "Hashing passwords" thread in pgsql-hackers list.
> >
> > But you are hashing it with a secret known by the database adminstrator,
> Yes, DB admin can gain useable info.
> 
> > and someone knows any password, like their own, can guess the secret by
> > looking at the hashed version, no?
> 
> No. Not any password, <master value> only. SHA or MD5 hash is one-way. There
> are many schemes. What I proposed is just one solution. Others may propose
> something better.
> 
> Here are my thoughts:
> 1. Yes, database admin can compromise security of the whole installation, no
> matter what security scheme is selected.
> 2. Even if database admin can compromise security, I would rather opt for a
> better security scheme, rather then give up completely.
> 3. When you enter your password at any login prompt, the password either
> appears as *** or does not appear at all. Why do you think it is done this
> way? Same applies to select * from pg_shadow.
> 4. Storing hashes instead of plain text passwords would divert all casual
> and "peek over the shoulder" hackers. It's two really different tasks -
> memorizing a password or memorizing 24 random-looking bytes of a base64 hash
> presentation.
> 6. People tend to reuse passwords. Getting one password helps to get other
> passwords too.
> 7. I do not understand why it's so important to keep passwords in plain
> text. Just a simple hash would help a lot.
> 
> Gene Sokolov.
> 
> 
> 
>