(3) I may no longer fully understand the implications of
"dictionary attack" and suspect that at least some
application writers understand it even less well that I
do. But, if my understanding is correct, it seems to me
that, if passwords or passphrases are readily vunerable
to dictionary attacks, there are other problems and the
presence of encryption would pose an inconvenience, not
an obstacle, for the attacker.
The strength of the encryption mechanism does not matter: if the
algorithm has been crypto-analyzed, then the attacker can just proceed
with a reverse computation. We don't know when a given algorithm will be
broken, but we can suspect that any algorithm will be broken eventually.
The reasonable design rule is thus to never hardcode a specific
encryption or hashing algorithm in a protocol.
Even with a strong algorithm, the only effective protection against
dictionary attacks is "key entropy", which determines the number of
trials needed before finding a match. This number follows Moore's law:
attackers with 2005 computers can attempt 100 times more trials than
attackers of 1995. We have reached a point where "if an average user can
remember the password, there is probably not enough entropy in it".
If you use simple hash functions like MD5 or SHA, challenge response
mechanisms are only OK if the shared secret contains at least as much
entropy as a good symmetric key. Most experts will assume that if you
can, you should use a randomly generated 128 bit key. In practice,
provisioning such keys is hard.
If you must use a low entropy key, you may have a solution by picking a
very slow encryption algorithm. Essentially, you would counter Moore's
law by requiring more CPU for a single trial. For example, instead of
using the simple SHA, you may want to iterate the algorithm 10,000
times. Any verification takes 10,000 times more than a simple trial, and
the dictionary attack becomes impractical. On the other hand, you have
increased the cost for the client and the server. You also rely on the
assumption that nobody can compute the result of 10,000 iterations
without iterating the algorithm 10,000 times, which may or may not be a
safe assumption.
CRAM-MD5 has another weakness that increases its vulnerability to
dictionary attack. In CRAM-MD5, the challenge is chosen by the server,
and the result computed by the client. An ill-intentioned server can
thus choose a challenge, and pre-compute a database of expected results.
A better algorithm should allow the client to inject some salt in the
process.
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf