Messages in this thread |  | | From | "Michael H. Warfield" <> | | Subject | Re: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC] | | Date | Sat, 12 Jun 1999 12:29:36 -0400 (EDT) |
| |
Justin Hahn enscribed thusly: > A Wik writes:
> aw> On Thu, 10 Jun 1999, Steve Dodd wrote: > >> > >> Rubbish. Store a secure one-way hash of the password. The problem is just > >> in choosing a secure algorithm. > aw> > aw> No, the one-way hashes are still sensitive (more so than a shadow file).
> Explain this. Any decent hash function has the following properties:
He's mixing apples and oranges... In another post it became clear that he's complaining about the fact that the hashes are used for other things. They are incorporated into the session keys and use for some cryptographic functions. The hashes in the shadow password file are not used in that way. So he's gripping about the hashes being sensitive because they are used for something in SMB land that has no functional equivalent for the shadow password file because it's not an integral part of a protocol.
IMHO, it's a red herring. He's complaining about the one-way hashes which are used for authentication because they are used for something other than authentication. I don't disagree that the protocol that they are used in is lame, but extrapolating that to argue that the hashes should be done away with (implying doing away with it for authentication as well) is just BOGUS. There was almost the implication that we could just magically wave our hands and do away with those hashes. Sorry, no way. We have to play by Microsoft's game to work with their protocols. We have to use those hashes to do that. We have to use them the same way they do. That's not our shot to call.
The protocol has gaping holes in it, no doubt. Unfortunately, Microsoft has to fix that and, when they do, they everything else. Just look at the problem from NT4 SP3 to SP4 with encrypted passwords. Now we're moving from SSP (Security Services Provider) version 1 to version 2. The version 1 protocol was incredibly lame! The version 2 is less so, but forget backward compatibility once that is fully enforced.
> - non invertible (or not trivially so) > - collision-"proof", that is it is computationally difficult to find > two inputs which result in the same output.
> (note that a good hash function need not be bijective, and I'd > conjecture that it shouldn't be)
> I don't see the sensitivity here.
He's blowing smoke. He's not complaining about the hashes or their reversability. He's complaining about the way they are used in a totally different area of the protocols and just not bothering to tell us until a recent post. If he had said that the protocol was lame and the way the hashes were used in the protocol was inappropriate, I don't think I would have disagreed with him. When he said that the hashes should be done away with because they were more sensitive than the shadow password file, he raised an inappropriate red-herring. His complaints have nothing to do with the authentication or the one-way hashes, just the protocol their used in. He also doesn't address what you would do if you eliminated the hashes. You certainly can't replace them with the shadow password file as he originally implied...
Time to let this one drop...
Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |