Gene Sokolov wrote:
>
> From: Hannu Krosing <hannu@trust.ee>
> >
> > 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.
This seems correct to me.
> [snip]
> 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.
But Hannu's point was that you can guard against network sniffing or you
can guard
against the evil 'select * pg_shadow', but not both.
While you're scheme _does_ secure against packet sniffing, it doesn't do
anything
against the select. So, you might as well just store 'password' and pass
back
hash := SHA(uid [+] password [+] randomval).
But I fully admit that cryptography is not my strong suit.
>
> Even more secure: don't store SHA(password) at the server but store
> SHA(password) XOR <mastervalue>.
I don't see how. I certainly know _my_ password. So I can compute
SHA(password). So,
if I can see what the database is storing, figuring out <mastervalue> is
a no brainer.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008