Hashing passwords (was Updated TODO list) - Mailing list pgsql-hackers

From Gene Sokolov
Subject Hashing passwords (was Updated TODO list)
Date
Msg-id 05a301beca04$2a098720$0d8cdac3@aktrad.ru
Whole thread Raw
In response to Re: [HACKERS] Updated TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Hashing passwords (was Updated TODO list)
List pgsql-hackers
From: Hannu Krosing <hannu@trust.ee>
> > > How about:
> > > * Not storing passwords in plain text
> >
> > But we don't, do we?  I thougth they were hashed.
>
> do
>  select * from pg_shadow;
>
> I think that it was agreed that it is better when they can't bw snatched
> from
> network than to have them hashed in db.
> Using currently known technologies we must either either know the
> original password
> and use challenge-response on net, or else use plaintext (or equivalent)
> on the wire.

I would be happier even with storing passwords at the server as a reversible
hash. For example, xor all user passwords with some value (for example
"PostgreSQL") and store base64(xor) strings instead of plain text.

Challenge-response authentication based on MD5 or SHA hashing would be
better, of course. A scheme like this would be reasonably secure:

1. Client initiates connection.
2. Server generates a long (16 byte) random value and passes it to the
client.
3. Client generates a one way hash of the user ID, SHA(password), and the
random number:
hash := SHA(uid [+] SHA(password) [+] randomval)
and sends openly uid and the hash back to the server
4. Server reconstructs the hash using stored SHA(password) and compares it
with the received hash.

Even more secure: don't store SHA(password) at the server but store
SHA(password) XOR <mastervalue>.

Gene Sokolov.





pgsql-hackers by date:

Previous
From: "Gene Sokolov"
Date:
Subject: Hashing passwords (was Updated TODO list)
Next
From: Louis Bertrand
Date:
Subject: Re: [HACKERS] Hashing passwords (was Updated TODO list)