| Re: [chrony-dev] Support for another crypto hash? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Mon, 7 Nov 2011, Ed W wrote:
On 07/11/2011 12:57, Miroslav Lichvar wrote:
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.
*IF* the attacker has access to the hashes, then unfortunately
bruteforce attacks are now reasonably feasible against even decent
length passwords that are typable on a normal keyboard. That was my
point about using a "slower" hash. It's only a linear improvement in
security, but it probably makes attacks significantly more tricky
See my previous post about how we can now do perhaps several hundred
million hashes per second on generic hardware. A change in hash can make
this 1-10 hashes per second on hardware that most people have access
to. If you only store the hash then this is a big improvement in security
And as I pointed out, that refers to a primative hash like MD5 or SHA2 which
were designed for speed. Instead all password hashes are purposely built to be
slow. They stick in all kinds of jiggery pokery so that on a typical machine
you get more like 100 hashes per second rather than a few Mega hashes per
second. The developers of the DES based Unix crypt(3) hash in 1970s already
understood this. Of course by 1990 their hash had become too fast on modern
machines, so a whole variety of others were developed, some of which allow you
to tune the number of iterations. However, you do not want to simply iterate a
hash. It is not clear that say MD5 itterated 1000 times cannot be replaced by
a single hash calculation which gives the same output but is the speed of a
single MD5. Also, the chances of entering a closed small cycle ( where many
many many passwords give the same iterated hash) become large the more
iterations you have. Thus they almost always include additional steps
(rearrangements of the bits, etc) to futher slow it down and to make the hash
more regular and unpredictable. (whether it actually does so is unkown.)
However, you state that you want to store the password? If so then you
can get security on the wire by not passing the real password across the
wire. Is this the use case we are talking about?
You certainly do not want to send the cleartext password across the wires. You
need some secrecy sharing (eg public key crypto, or diffie Helman generation
of a shared "random" number.).
There are I think two places where chrony uses passwords. One is in chronyc to
allow a user to execute sensitive remote commands. The other is in the
password protected ntp exchange, to ensure that the sources of your time have
not been subverted by an adversary-- imaginge the problems is you are a
currency trader, and your clock is made 10 seconds fast.
Sorry, bit confused about where we need a password and where a hash
Point anyway is that if the hash is leaked then bruteforcing is
extremely feasible unless a "slow" hash is used. I think that
summarises my side of the topic!
Hashes are used for two things-- verification, and password checking.
Verification is fine to use a fast hash (Ie, making sure that the message has
not been changed in transmission to you.) Password checking needs a slow hash
to protect against database leaks.
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.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
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.