Re: [chrony-dev] Support for another crypto hash?

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Sat, Nov 05, 2011 at 04:39:10PM +0000, Ed W wrote:
> Hi
> 
> 
> > I couldn't find a specification for the extended format.
> 
> I think it's RFC2307.  However, I am slightly confused on where it's
> implemented.  I think glibc only handles the old funny $a2... encodings,
> however, the format I referred to is widely used elsewhere and
> integrated into many other applications:

Thanks. In our case we store the passwords instead of hashes, so we want
to be able to store also the {} chars. Do you think it's a bad idea to
just require that all keys with specified hash are in hex? This could
also make the users set randomly generated passwords and thus avoid
the problem with dictionary attacks.

> >> - It would be nice if the password were not stored in the clear on the
> >> ntp box.  However, with the exception of public key crypto, this is at
> >> odds with secure password exchange on the wire...
> > If the keyfile was encrypted, the key to that file would still have to
> > be somewhere in cleartext, or how would be chronyd started?
> 
> I mean it's desirable that the password hash alone is stored in the
> chrony.keys file.  Sure we can ask who cares, but we hash all the normal
> user login passwords because we don't want users with local file access
> to see them.  And if the password is hashed then make it a really good
> hash so that it can't be trivially reversed out in a few seconds using a
> cracker...
> 
> The problem with hashed passwords is that they preclude keeping the
> password secret on the wire.  ie roughly:
> - known plaintext password at each end = no plaintext password swapped
> across the network (use digest auth of some kind)
> - hashed password at each end = plaintext password swapped across the
> network (hence vulnerable to sniffing)
> 
> You can't have things both ways...

So you are proposing to change the authentication for the cmdmon
protocol? Currently we use the exactly same MAC as is used in NTP. I'm
no crypto expert, unless there is a serious problem with it I'd like
to keep it that way :).

-- 
Miroslav Lichvar

---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.