From: Mark Hollomon <mhh@nortelnetworks.com>
> > 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.
[snip]
> 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.
I cannot fully agree:
1. Select in this case would give you a value, which you have to use from a
*custom* modified client. Any standard client would not be able to use it.
2. Many people use the same or similar passwords for all logins. Just
obfuscating the passwords would be beneficial for them.
3. See below.
> > 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.
Ok, make it SHA(pass) XOR SHA(mastervalue [+] uid). This way you can't get a
useful info without knowing the master value.