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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.