Challenge-response protocol: Difference between revisions
imported>Sandy Harris No edit summary |
imported>Sandy Harris No edit summary |
||
| Line 2: | Line 2: | ||
A '''challenge-response protocol''' is a technique for managing [[information security#source authentication|source authentication]]. | A '''challenge-response protocol''' is a technique for managing [[information security#source authentication|source authentication]]. | ||
As a simple example, consider a user who wants to log in to a computer system. If he sends the actual password, or a [[Hash (cryptography)|hash]] of it, over the wire, then a wiretapper can get it. Moreover, if an attacker can obtain | As a simple example, consider a user who wants to log in to a computer system. If he sends the actual password, or a [[Hash (cryptography)|hash]] of it, over the wire, then a wiretapper can get it. Moreover, if an attacker can obtain a list of encrypted passwords from the target system, either by reading it from an account on the system or by intercepting them on the wire, then he can conduct a [[dictionary attack]] and break into any account whose password is in the dictionary. | ||
In a challenge-response protocol, the interaction might go like this instead: | In a challenge-response protocol, the interaction might go like this instead: | ||
Revision as of 19:26, 20 August 2010
A challenge-response protocol is a technique for managing source authentication.
As a simple example, consider a user who wants to log in to a computer system. If he sends the actual password, or a hash of it, over the wire, then a wiretapper can get it. Moreover, if an attacker can obtain a list of encrypted passwords from the target system, either by reading it from an account on the system or by intercepting them on the wire, then he can conduct a dictionary attack and break into any account whose password is in the dictionary.
In a challenge-response protocol, the interaction might go like this instead:
- the user requests a connection
- the system generates a random challenge C, using a strong random number generator
- the system sends C to the user
- the user encrypts C with a block cipher, using the hash of his password as key, to generate the response R
- the user sends R back to the system
- the system decrypts R, using the stored hash of the user password as key
- if the result is C, the connection is allowed
There are many variations. The example uses a block cipher, but it can also be done with public key techniques — the user encrypts with his private key in step 4 and the system verifies with the public key in step 6. A hash can also be used — step 4 is then to hash some combination of data that includes the challenge and the hashed password to get R, and step 6 is to hash the same data and compare the result to R.
In any case, the actual password is never transmitted. An eavesdropper can see C and R each time, but that does him little good. Next time a different challenge will be used and a different response required. If the cryptography used is sound, then even with a large collection of challenge/response pairs, it should be very difficult for him to discover anything about the password.
The challenge must be large enough to prevent a birthday attack. With a challenge of 2n bits, an attacker who logs the data from 2n/2 interactions has a significant chance of seeing a repeated challenge.