Gene Sokolov wrote:
>
> From: Mark Hollomon <mhh@nortelnetworks.com>
> > 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.
Okay, so only the 'casual cracker' is involved. I don't have a problem
as long
as long as that is stated.
>
> > > 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.
That is better. But, under the 'casual cracker' senario, I don't think
this is necessary.
Also, the unspoken assumption is that mastervalue is site specific, say
randomly
generated at initdb time. But ouch, that sure makes upgrades dicey. And
we would
have to think carefully about where to store it.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008
