lkml.org 
[lkml]   [1999]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC]
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site