Computer Security :: Lessons :: User Authentication
Principles of Remote User Authentication
Authenticating a user consists of two steps: the identification step where the user presents an identifier to the security system and the verification step where the authentication information verifies the binding between the entity and the identifier. There are four general ways of authenticating a user's identity:
- Something the individual knows: Examples include a password, a personal identification number (PIN), or answers to prearranged security questions.
- Something the individual possesses: Examples include cryptographic keys, electronic keycards, smart cards, and physical keys. This type of authentication is referred to as a token.
- Something the individual is (static biometrics): Examples include recognition by fingerprint, retina, and face.
- Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting, and typing.
All of the above methods can provide secure user authentication, but they all have problems. A password or PIN can be stolen or guessed. False positives and false negatives can hamper the usefulness of biometric authentication. Tokens can be lost or stolen. Because of this, mutual authentication protocols are typically used.
Two problems need to be addressed to use mutual authentication protocols: confidentiality and timeliness. To prevent masquerade and the compromise of session keys, essential identification and session-key information must be communicated in encrypted form. This requires the prior existence of secret or public keys. Timeliness is important because of the threat of message replays. A replay attack could allow an opponent to compromise a session key or successfully impersonate another party. The following are examples of replay attacks:
- The simplest replay attack is one in which the opponent simply copies a message and replays it later.
- An opponent can replay a timestamped message within the valid time windows. If both the original and the replay arrive within the time window, this incident can be logged.
- As with the second example, an opponent can replay a timestamped message within the valid time window, but in addition, the opponent suppresses the original message. Thus, the repetition cannot be detected.
- Another attack involves a backward replay without modification. This is a replay back to the message sender. This attack is possible if symmetric encryption is used and the sender cannot easily recognize the difference between messages sent and messages received on the basis of content.
One approach to coping with replay attacks is attaching a sequence number to each message used in an authentication exchange. A new message is only accepted if its sequence number is in the proper order. There is a lot of overhead with sequence numbers, however, so timestamps or nonces are typically used instead.
Kerberos
Kerberos is an authentication service developed at MIT. Kerberos was made to combat the following three threats:
- A user may gain access to a particular workstation and pretend to be another user operating from that workstation.
- A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.
- A user may eavesdrop on exchanges and use a replay attack to gain entrance to a server or to disrupt operations.
Version 4 of Kerberos uses DES and is still widely used. Version 5, however, was put into use to address some of the deficiencies of Version 4 including the following:
- Double encryption: Tickets provided to clients in Version 4 are encrypted twice, once with the secret key of the target server and then again with a secret key known to the client. The second encryption is unnecessary and computationally wasteful.
- PCBC encryption: Version 4 uses a nonstandard mode of DES known as propagating cipher block chaining (PCBC) that is vulnerable to attack involving the interchange of ciphertext blocks.
- Session keys: Each ticket includes a session key that is used by the client to encrypt the authenticator sent to the service associated with that ticket. However, because the same ticket may be used repeatedly to gain service from a particular server, there is the risk that an opponent will replay messages from an old session to the client or the server. Version 5 addresses this with the use of a subsession key that is used for just one connection.
- Password attacks: Version 4 and version 5 are both vulnerable to a password attack. The message from the authentication server to the client includes material encrypted with a key based on the client's password. An opponent can capture this message and attempt to decrypt it by trying various passwords. If the result of a test decryption is successful, then the opponent has discovered the client's password.
