cjr@SIMPACT.COM (Chris Riddick) (05/21/91)
My note: >> From: Chris Riddick <cjr@simpact.COM> >> >> There is a way to render the dictionary attack ineffective. That is the use >> of one-time passwords. With a onetime password, even a TGT that was stolen >> simply by eavesdropping during login would not be useful. The password that >> was extracted via the dictionary attack (other other cryptanalysis) was only >> good for that login (i.e., TGT). The next time the user logs in, a >> different password will be required. You responded with: > No. "One-time passwords" (this is really the wrong term for >this, but I know what you mean from the previous time you explained >yourself), do NOT by themselves render the dictionary attack >ineffective. If the user chooses his/her own master password, the fact >that one-time passwords are generated from it will not make the attack >impossible. [The details of how to alter the attack to deal with this >are left to the reader.] > > However, forcing the user to use a randomly generated password >will render the dictionary attack useless. Granted, this is >particularly easy to do when the user already has to carry a one-time >password generator device around with him/her. You made an assumption that the method used to generate the one-time password depended upon a seed value chosen by the user. If the method of generating the one-time password can be shown to protect the seed value, then simply breaking the encryption to get into the TGT only gives the onetime password. You cannot reuse the TGT and the password cannot be reused. If you have no way of working back to the original seed value, then you have rendered attack ineffective (other than deciphering the TGT, which exposes the session key between the user and the Kerberos server). There are two threats to protect against here. The first is the protection of the password for kerberos login. The second is the privacy of the communications between the user and the kerberos server. A properly generated one-time password will protect the kerberos login. However, any successful cryptographic attack against the TGT will expose the session key. Obviously, a proper solution has to address both of these vulnerabilities. The key aspect of the onetime password is that we can ensure that the attacker does not gain access to the kerberos server to get another TGT (an auditable event). The user is vulnerable during the period before the TGT expires/revoked if the encryption is broken. Chris Riddick
mdl@B.GP.CS.CMU.EDU (Mark Lillibridge) (05/21/91)
> From: Chris Riddick <cjr@simpact.COM> > Date: Tue, 21 May 91 8:38:27 EDT > > ... > > You made an assumption that the method used to generate the one-time > password depended upon a seed value chosen by the user. If the seed value is chosen by the user, you could have a problem with dictionary attacks. If the seed value is chosen randomly, obviously, you can't have a problem with a dictionary attack as there is no dictionary involved. The later case solves the problem but the use of one-time passwords is not why it does so. The randomly chosen key is the reason. >If the method > of generating the one-time password can be shown to protect the seed > value, then simply breaking the encryption to get into the TGT only gives the > onetime password. You cannot reuse the TGT and the password cannot be > reused. If you have no way of working back to the original seed value, > then you have rendered attack ineffective (other than deciphering the TGT, > which exposes the session key between the user and the Kerberos server). Let me give a concrete example. Suppose the user chose "Fred" as her password. Now, when it is time to log in, Kerberos picks a random key r. Kerberos then encrypts r with a key derived from "Fred" to get k. Kerberos then sends the normal TGT information encrypted with k together with r. The user is then challenged with r. She types r into her handheld which encrypts it with the key derived from "Fred", thus obtaining k which it then displays. She then types in k and authentication proceeds in the obvious manner. I would call this a "one-time password system". Let me know if you disagree. How can I check if her password is "Fred"? Well, I take a handheld, type in "Fred" as the key then r [from a previous TGT request]. If the handheld responds with k, her password is indeed "Fred", otherwise it is not. Thus, by this technique, given a r-k pair from a previous successful login, I can very quickly discover the user's password if it is in a small dictionary. This meets my definition of a successful dictionary attack. I note that by using randomness on both sides of the connection, it may be possible to foil dictionary attacks. I mentioned this in my first reply. However, the protection comes from the randomness, not the one-time password part. - Mark Lillibridge
cjr@SIMPACT.COM (Chris Riddick) (05/22/91)
You are correct in your description of a one-time password system. The attack you described does take advantage of the vulnerability created by using a user-selected password and a handheld that transforms the password into a key. However, there other forms of one-time password systems that DO NOT derive the one-time key from a user-entered value, but rather are synchronized from time zero between the host (kerberos) and the user (handheld). The paper analog to this is the classic one-time pad used by the cloak and dagger people in the government. In this system, there are two sets of pads, one for the encryptor and one for the decryptor. They both start at the same place on the pad using the same sequence of random bits to begin the encryption. As the bits are used, they are thrown away. If you ever get out of sequence, your're in trouble. But it is very effective and very secure. The ONLY way for someone to break the encryption is to steal one of the two pads. Now, if we were to simplify this paper technique into something that generated a one-time password while synchronized between the encryptor and decryptor, then we would be able to avoid any sort of dictionary attack because the key is not generated from a password entered by a user, but from a seed embedded in a handheld AND synchronized with the seed and key generator at the host (Kerberos). Even if you knew the seed and the algorithm, you would still have the problem of synchronization to contend with. If the recomputing of the key is performed often enough (say, every 30-60 seconds), it doesn't leave much opportunity to for an attacker to generate the key and beat you to the login. Realize that once used, the key is not reused. The next valid key will be the next i in sequence generated by the handheld. There is still a vulnerability here, but it IS NOT due to a dictionary attack. It is that the attacker COULD acquire the handheld, acquire the user's PIN (used just like the PIN for an ATM at a bank), and then log in as that user. The attacker could also perform cryptanalysis on the TGT that is returned encrypted in the special one-time password. If successful, he would be able to decrypt the TGT. However, he would NOT have the user's password. Everytime he wanted to do this he would have to perform the cryptanalysis on the TGT to get the one-time password. This limits the vulnerability to the lifetime of the TGT rather than to the lifetime of the password. As Jon so aptly noted, security is a matter of degree. You implement only as much as you feel your threats and assets require. Any more is a waste of resources. I believe that for many environments, what we have been discussing over the past couple of days is NOT a threat that would be assigned a high risk value. That does not allow us to ignore the fact that there is a threat, so we need to carry on these types of analyses to find out if there are holes in any of the mechanisms. It is obvious that there are serveral types of one-time systems. It is also apparent that we have been discussing more than one threat. I am in agreement with you about the attacks on the password system you described, but I believe I was thinking about a different problem, and that was of the elimination of the user-defined password altogether. -- Chris