690 likes | 782 Views
AUTHONTICATION. User Authentication. Use of Passwords Attacks on Passwords Password Selection Criteria The Authentication Process Flaws in the Authentication Process Authentication Other Than Passwords. Authentication Methods. Name-based Verification of basic, available information
E N D
User Authentication • Use of Passwords • Attacks on Passwords • Password Selection Criteria • The Authentication Process • Flaws in the Authentication Process • Authentication Other Than Passwords
Authentication Methods • Name-based • Verification of basic, available information • IP address, MAC address, DNS domain, etc. • Difficult to implement • Not very secure • Password-based • Works on a challenge-response scheme • Username prompts a challenge from a server • Password is rarely sent over the network • Secure, but still susceptible to dictionary attacks • Token-based • User carries a hardware token device with a changing key • The key, in conjunction with a password, is used to provide a response to a challenge
Authentication Methods (cont) • Cryptographic • Based on known crypto and hashing methods • Users are issued a certificate to prove their identity • Certificate is signed by a trusted third-party • Biometric • Bio: life; Metric: measure • Uses body properties to authenticate a user • Fingerprint • Retina and iris scan • DNA? • Biometric data is used as a token, similar to token-based
Use of Passwords Passwords are mutually agreed-upon code words, assumed to be known only to the user and the system. The use of of passwords is fairly straightforward. A user enters some piece of identification, such as a name or an assigned user ID, if the identification matches that on file for the user, the user is authenticated to the system. If the identification match fails, the user is rejected by the system.
Password Storage • When users enter passwords for the network or operating system, they or some facsimile of them must be stored so there is something to compare user login attempts to. There are three primary choices for password storage: • Clear text • Encrypted password • Hash value of a password - Used by Unix and Windows NT • The storage locations may be: • Root or administrator readable only • Readable by anyone. • Passwords are more secure when they can only be read by the administrator or root account. Also the best password storage security is to store the hashed value of a password.
Password Protection and Cracking • Passwords should be chosen wisely and a dictionary word should never be used. This is because if an attacker can get the hashed or encrypted value of a password, they can run password guessing programs to eventually guess the password by comparing the encrypted result of the guess to the actual encrypted password. The easiest password attack is a dictionary attack where dictionary words are used to guess the password. Other attacks include a brute force attack which can take much longer than a dictionary attack. This is why passwords should have a minimum length and a minimum degree of complexity. The complexity requirements should include three of four of the following four types of characters: • Lowercase • Uppercase • Numbers • Special characters such as !@#$%^&*(){}[]
Attacks on Passwords • Try all possible passwords • exhaustive or brute force attack • Try many probable passwords • Users do not likely select a password uncommon, hard to spell or pronounce, very long • Try passwords likely for the user • Password generally is meaningful to the user
Attacks on Passwords (cont’) • Search for the system list of passwords • Finding a plain text system password list • Ask the user • Get the password directly from the user.
Authentication Protocols • CHAP - Challenge Handshake Authentication Protocol is a three way handshake protocol which is considered more secure than PAP. Authentication Protocol. • EAP - Extensible Authentication Protocol is used between a dial-in client and server to determine what authentication protocol will be used. • PAP - Password Authentication Protocol is a two way handshake protocol designed for use with PPP. Authentication Protocol Password Authentication Protocol is a plain text password used on older SLIP systems. It is not secure. • SPAP - Shiva PAP. Only NT RAS server supports this for clients dialing in. • DES - Data Encryption Standard for older clients and servers. • RADIUS - Remote Authentication Dial-In User Service used to authenticate users dialing in remotely to servers in a organization's network. • S/Key - A one time password system, secure against replays. RFC 2289. Authentication Protocol. • TACACS - Offers authentication, accounting, and authorization. Authentication Protocol. • MS-CHAP (MD4) - Uses a Microsoft version of RSA message digest 4 challenge and reply protocol. It only works on Microsoft systems and enables data encryption. Selecting this authentication method causes all data to be encrypted. • SKID - SKID2 and SKID3 are vulnerable to a man in the middle attack.
The Authentication Process • Intentionally slow • This makes exhaustive attack infeasible • identify intruder from the normal user • some who continuously fails to login may not be an authorized user. • System disconnect a user after three to five failed logins
Introduction • PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase. By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
Protocols to send passwords • PAP - Password Authentication Protocol - Used with Point to Point Protocol (PPP). The password is sent in the clear. • CHAP - Challenge handshake authentication protocol is preferred rather than PAP since the actual password is not sent across the internet or network.
Password Authentication Scenario 1 I need access Client Server Authenticate yourself I am “A”, password “QWERTY” “A” password “QWERTY”? Yes / No Access granted / denied • Shared secret: password • This scenario is not secure: password is sent in plaintext • Used by PAP (Password Authentication Protocol)
PAP • Short for Password Authentication Protocol, the most basic form of authentication, in which a user's name and password are transmitted over a network and compared to a table of name-password pairs. Typically, the passwords stored in the table are encrypted. The Basic Authentication feature built into the HTTP protocol uses PAP. The main weakness of PAP is that both the username and password are transmitted "in the clear" -- that is, in an unencrypted form
PAP: Password Authentication Protocol • RFC 1334 • Password must be protected on both systems • Susceptible to eavesdropping and replay attacks • Serves as client authentication only: server could be an impostor • PAP was developed for the Point-to-Point Protocol PPP • Served well when connection was established on a dial-up line • PPP connections can now be established over shared networks (such as Ethernet using PPPoE) • PAP is no longer used because considered not secure
PPP Authentication • Most manufacturers support both PPP authentication schemes • PAP: Password Authentication Protocol (RFC 1334) • CHAP: Challenge Handshake Authentication Protocol (RFC 1994) • PAP uses a simple two-way handshake • Peer router/dial-up system repeatedly sends identifier/password to authenticator • Stops when password acknowledged or link cleared • Once password is established, no further authentication is required • PAP identifier and password are sent as clear text PEER AUTH ID/password PAP authentication OK
PAP • PAP provides a simple method for the peer to establish its identity using a 2-way handshake. This is done only upon initial link establishment. • After the Link Establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. • PAP is not a strong authentication method. Passwords are sent over the circuit "in the clear", and there is no protection from playback or repeated trial and error attacks. • This authentication method is most appropriately used where a plaintext password must be available to simulate a login at a remote host. In such use, this method provides a similar level of security to the usual user login at the remote host.
Packet Format Exactly one Password Authentication Protocol packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex c023 (Password Authentication Protocol). A summary of the PAP packet format is shown below. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+| Peer-ID Length| Peer-Id ... • | Passwd-Length | Password ... +-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 1 for Authenticate-Request. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be changed each time an Authenticate-Request packet is issued. Peer-ID-Length The Peer-ID-Length field is one octet and indicates the length of the Peer-ID field. Peer-ID The Peer-ID field is zero or more octets and indicates the name of the peer to be authenticated. Passwd-Length The Passwd-Length field is one octet and indicates the length of the Password field. Password The Password field is zero or more octets and indicates the password to be used for authentication.
Authenticate-Ack and Authenticate-Nak • Description If the Peer-ID/Password pair received in an Authenticate-Request is both recognizable and acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 2 (Authenticate- Ack). If the Peer-ID/Password pair received in a Authenticate-Request is not recognizable or acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 3 (Authenticate- Nak), and SHOULD take action to terminate the link. A summary of the Authenticate-Ack and Authenticate-Nak packet format is shown below.
IIT NAS Alice ID = Alice, Password = ??? Protocol Information Padding Authenticate-Ack or Authenticate-Nak 0XC023=PAP Code Identifier Data Length 1 byte Host ID Size Host ID Password Size Password PAP (cont.)
Password Authentication Scenario 2 I am “A”, I need access Client Server CHAP Challenge: H6ty”1@!p Compute Response CHAP Response: Answer: 89it%-QkL Query “A”’s password Compute response Match? CHAP Access granted / denied • Shared secret: password • Challenge by B: randomly generated number • Response by A: Hash of (Password + Random Challenge) • Used by CHAP (Challenge Handshake Authentication Protocol)
Challenge Handshake Authentication Protocol (CHAP) • RFC 1994 • CHAP protects against eavesdropping since password is never sent • It also protects against replay attacks because a random number is used • It is however vulnerable to dictionary and brute force attacks • Both the challenge and the response are visible • Hash method used by CHAP is MD5 • RFC 1321
CHAP Authentication CHAP authentication challenge PEER AUTH secret Ack • CHAP provides much stronger authentication than PAP • Uses three-way handshake • Authenticator sendschallengeto peer • Peer responds with the secret • A value calculated with aone-way hash function • Known only to the twoparties involved • Authenticator recalculates secret and compares with one received • If the values match, the authentication is acknowledged • Otherwise, the connection is terminated • Challenge can be re-issued at any time during call
Challenge-Handshake Authentication Protocol • Challenge-Handshake Authentication Protocol The Challenge-Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment, and MAY be repeated anytime after the link has been established. After the Link Establishment phase is complete, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated using a "one-way hash" function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection SHOULD be terminated. CHAP provides protection against playback attack through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges. This authentication method depends upon a "secret" known only to the authenticator and that peer. The secret is not sent over the link. This method is most likely used where the same secret is easily accessed from both ends of the link.
CHAP Authentication • The CHAP algorithm requires that the length of the secret MUST be at least 1 octet. The secret SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least the length of the hash value for the hashing algorithm chosen (16 octets for MD5). This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The one-way hash algorithm is chosen such that it is computationally infeasible to determine the secret from the known challenge and response values. The challenge value SHOULD satisfy two criteria: 1-uniqueness and 2-unpredictability. Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. Each challenge value SHOULD also be unpredictable, least an attacker trick a peer into responding to a predicted future challenge, and then use the response to masquerade as that peer to an authenticator.
Configuration • A summary of the Authenticate-Request packet format is shown below. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ...
Packet Format • Code 1 for Challenge; 2 for Response. Identifier The Identifier field is one octet.(A unit of data that consists of exactly 8 bits) • The Identifier field MUST be changed each time a Challenge is sent. The Response Identifier MUST be copied from the Identifier field of the Challenge which caused the Response. Value-Size This field is one octet and indicates the length of the Value field. Value The Value field is one or more octets. The most significant octet is transmitted first. The Challenge Value is a variable stream of octets. The importance of the uniqueness of the Challenge Value and its relationship to the secret is described above. The Challenge Value MUST be changed each time a Challenge is sent. The length of the Challenge Value depends upon the method used to generate the octets, and is independent of the hash algorithm used. The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL. The size is determined from the Length field. Since CHAP may be used to authenticate many different systems, the content of the name field(s) may be used as a key to locate the proper secret in a database of secrets. This also makes it possible to support more than one name/secret pair per system.
Description • Description The Challenge packet is used to begin the Challenge-Handshake Authentication Protocol. The authenticator MUST transmit a CHAP packet with the Code field set to 1 (Challenge). Additional Challenge packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. A Challenge packet MAY also be transmitted at any time during the Network-Layer Protocol phase to ensure that the connection has not been altered. The peer SHOULD expect Challenge packets during the Authentication phase and the Network-Layer Protocol phase. Whenever a Challenge packet is received, the peer MUST transmit a CHAP packet with the Code field set to 2 (Response). Whenever a Response packet is received, the authenticator compares the Response Value with its own calculation of the expected value. Based on this comparison, the authenticator MUST send a Success or Failure packet (described below).
Success and Failure • If the Value received in a Response is equal to the expected value, then the implementation MUST transmit a CHAP packet with the Code field set to 3 (Success). If the Value received in a Response is not equal to the expected value, then the implementation MUST transmit a CHAP packet with the Code field set to 4 (Failure), and SHOULD take action to terminate the link.
IIT NAS Alice ID, Random Number, IIT ID, Pwd, Random No. MD5 Hash response Protocol Information Padding 0xC223=CHAP ID, Pwd, Random No. ID, Hash response, Alice MD5 Code Identifier Length Data Hash Value, match? Success or Failure Value-Size Value Name CHAP (cont.)
About CHAP and PAP IP Network • Both CHAP and PAP protocols were created to manage remote access users • Low-level authentication: controls access to network resources • First iteration: dial-up networking using Point-to-Point Protocol (PPP) • New uses: • Wi-Fi using WEP security (Wired-Equivalent Privacy) • PPPoE (PPP over Ethernet, used for ADSL user authentication) • Because of the decentralized nature of dial-up networks, a technology for central authentication is often required Remote Access Server Authentication Server (central user database) Remote Access Server
RADIUS IP Network • RFC 2865 • Remote Authentication Dial-In User Service • Three-party authentication • Client (supplicant), request access to the network • Authenticator is the supplicant’s first contact to the network • Ethernet switch • Wi-Fi Access point • PPP end-point • Authentication Server contains the user database and grants or denies access RADIUS Authenticator Client (Supplicant) Authentication Server
RADIUS Scenario 1 Client (Requestor) Authenticator Authentication Server I am “A”, I need access CHAP Challenge CHAP Response RADIUS Access-Request RADIUS Access-Accept / Reject CHAP Success / Failure
RADIUS Scenario 1 (cont.) • The Authenticator challenges the client upon request and collects the Client’s response to the CHAP challenge • The Authenticator sends to the Authentication Server the username, ID, random number and client response (CHAP MD5 hash) in the Access-Request packet • The Authentication Server computes the MD5 hash using the ID, client’s password and random number and replies with an Access-Accept or an Access-Failure packet • The Authenticator forwards the information to the client in the form of a CHAP Success or CHAP Failure packet
RADIUS Scenario 2 Client (Requestor) Authenticator Authentication Server I am “A”, I need access RADIUS Access-Request RADIUS Access-Challenge CHAP Challenge CHAP Response RADIUS Access-Request RADIUS Access-Accept / Reject CHAP Success / Failure
RADIUS Scenario 2 (cont.) • The Authenticator, upon request, sends to the Authentication Server a RADIUS Access-Request. • The password is set to a knowingly wrong value such as the string “empty” or “void” to prompt a challenge from the server • The Authentication Server sends a RADIUS Access-Challenge packet which is forwarded to the client in the form of a CHAP Challenge • The client responds using the normal CHAP method • The rest of the procedure follows Scenario 1
Notes on RADIUS Scenarios 1 and 2 • Why use one method or the other? • In some cases, the Authenticator is programmed to take a load off the Authentication Server and will provide the CHAP Challenge itself • In some other cases, it is better to have the Authentication Server provide challenges from a central location to assure uniqueness of challenges and prevent replay attacks • It is the case when the Authenticator is a wireless Access Point • In both scenarios, the Authenticator and Authentication Server share a secret key that is used to further encrypt the information and prevent replay attacks on that segment
RADIUS • Remote Authentication Dial-In User Service (RADIUS) is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access. Originally developed for dial-up remote access, RADIUS is now supported by virtual private network (VPN) servers, wireless access points, authenticating Ethernet switches, Digital Subscriber Line (DSL) access, and other network access types. RADIUS is described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," (IETF Draft Standard) and RFC 2866, "RADIUS Accounting" (Informational).
Key features of RADIUS • Client/Server Model A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
Network Security Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.