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

[Ed W <lists@xxxxxxxxxxxxxx>]

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:

See:
    http://www.kernel.org/doc/man-pages/online/pages/man3/crypt.3.html
   
http://search.cpan.org/~zefram/Authen-Passphrase-0.007/lib/Authen/Passphrase.pm
    http://wiki.dovecot.org/Authentication/PasswordSchemes
    http://www.faqs.org/rfcs/rfc2307.html
   

>> - The unix crypt functions are extended in recent glibc (and I posted a
>> uclibc patch recently) to include multiple iterated algorithms with a
>> view to making bruteforce more difficult. This is something worth
>> picking up on now that GPUs compute hashes at >100million per second...
>> Salt doesn't help you against that, so long, complex passwords are
>> necessary if you need resistance to bruteforcing password hashes...
>> (multiple iteration algorithms partially mitigate this)
> I'm not sure I understand how this works. The same hash function is
> used multiple times on the same data?

Hash generators have reached speeds of several hundred million hashes
per second, eg:
    http://www.cryptohaze.com/multiforcer.php

In real terms this means it takes only hours to fully bruteforce an 8
digits password drawn from a 50 digit alphabet (ie most random junk you
could type even if you can actually remember a password like: $"*&)(_34

As such it's starting to get impractical to hash a reasonable length
password and not have it bruteforced in seconds/minutes on a standard
PC.  A temporary workaround is to make the hash function slower. 
Roughly you run your algorithm multiple times where "multiple" is chosen
to make it hard to check more than a small number of hashes per second. 
It's an imperfect technique, but seems to be better than nothing


>> - 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...

(The closest to having it work both ways is public key encryption)



However, I concede that I'm not actually sure which hashes you are
referring to here, so my suggestions on format above were really more
about exactly that, format.  Others have standardised on a particular
format string, suggest you go with that.

Good luck

Ed W
>


---
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.