AUTHONTICATION. User Authentication §Use of Passwords §Attacks on Passwords §Password Selection Criteria §The Authentication Process §Flaws in the Authentication.

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 l Verification of basic, available information l IP address, MAC address, DNS domain, etc. l Difficult to implement l Not very secure §Password-based l Works on a challenge-response scheme l Username prompts a challenge from a server l Password is rarely sent over the network l Secure, but still susceptible to dictionary attacks §Token-based l User carries a hardware token device with a changing key l The key, in conjunction with a password, is used to provide a response to a challenge

Authentication Methods (cont) §Cryptographic l Based on known crypto and hashing methods l Users are issued a certificate to prove their identity l Certificate is signed by a trusted third-party §Biometric l Bio: life; Metric: measure l Uses body properties to authenticate a user Fingerprint Retina and iris scan DNA? l 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 l exhaustive or brute force attack §Try many probable passwords l Users do not likely select a password uncommon, hard to spell or pronounce, very long §Try passwords likely for the user l Password generally is meaningful to the user

Attacks on Passwords (cont’) §Search for the system list of passwords l Finding a plain text system password list §Ask the user l 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 l This makes exhaustive attack infeasible §identify intruder from the normal user l some who continuously fails to login may not be an authorized user. l 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 l Shared secret: password l This scenario is not secure: password is sent in plaintext l Used by PAP (Password Authentication Protocol) I need access Authenticate yourself I am “A”, password “QWERTY” Access granted / denied ClientServer “A” password “QWERTY”? Yes / No

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 l RFC 1334 l Password must be protected on both systems l Susceptible to eavesdropping and replay attacks l Serves as client authentication only: server could be an impostor l PAP was developed for the Point-to-Point Protocol PPP l Served well when connection was established on a dial-up line l PPP connections can now be established over shared networks (such as Ethernet using PPPoE) PAP is no longer used because considered not secure

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 PAP authentication PEER AUTH ID/password OK PPP Authentication

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.

§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.

PAP (cont.) IIT NAS Alice ID = Alice, Password = ??? Authenticate-Ack or Authenticate-Nak InformationPadding Protocol 0XC023=PAP Identifier Length Code 1 byte Data Host ID Password Size Host ID Size Password

Password Authentication Scenario 2 l Shared secret: password l Challenge by B: randomly generated number l Response by A: Hash of (Password + Random Challenge) l Used by CHAP (Challenge Handshake Authentication Protocol) I am “A”, I need access CHAP Challenge: H6ty”1@!p CHAP Response: Answer: 89it%-QkL CHAP Access granted / denied ClientServer Query “A”’s password Compute response Match? Compute Response

Challenge Handshake Authentication Protocol (CHAP) l RFC 1994 l CHAP protects against eavesdropping since password is never sent l It also protects against replay attacks because a random number is used l It is however vulnerable to dictionary and brute force attacks Both the challenge and the response are visible l Hash method used by CHAP is MD5 RFC 1321

CHAP Authentication CHAP provides much stronger authentication than PAP –Uses three-way handshake 1.Authenticator sends challenge to peer 2.Peer responds with the secret –A value calculated with a one-way hash function »Known only to the two parties involved 3.Authenticator recalculates secret and compares with one received –If the values match, the authentication is acknowledged »Otherwise, the connection is terminated 4.Challenge can be re-issued at any time during call Ack CHAP authentication PEER AUTH secret challenge

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.

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.

CHAP (cont.) IIT NAS Alice ID, Random Number, IIT Success or Failure ID, Pwd, Random No. MD5 Hash response ID, Hash response, Alice ID, Pwd, Random No. MD5 Hash Value, match? InformationPadding Protocol 0xC223=CHAP IdentifierLength Code Data ValueNameValue-Size

About CHAP and PAP l Both CHAP and PAP protocols were created to manage remote access users l Low-level authentication: controls access to network resources l First iteration: dial-up networking using Point-to-Point Protocol (PPP) l New uses: Wi-Fi using WEP security (Wired-Equivalent Privacy) PPPoE (PPP over Ethernet, used for ADSL user authentication) l Because of the decentralized nature of dial-up networks, a technology for central authentication is often required IP Network Authentication Server (central user database) Remote Access Server Remote Access Server

RADIUS l RFC 2865 l Remote Authentication Dial-In User Service l 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 IP Network Client (Supplicant) Authenticator Authentication Server RADIUS

RADIUS Scenario 1 Client (Requestor) AuthenticatorAuthentication 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.) l The Authenticator challenges the client upon request and collects the Client’s response to the CHAP challenge l The Authenticator sends to the Authentication Server the username, ID, random number and client response (CHAP MD5 hash) in the Access-Request packet l 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 l The Authenticator forwards the information to the client in the form of a CHAP Success or CHAP Failure packet

RADIUS Scenario 2 Client (Requestor) AuthenticatorAuthentication Server I am “A”, I need access CHAP Challenge CHAP Response RADIUS Access-Request RADIUS Access-Accept / Reject CHAP Success / Failure RADIUS Access-Request RADIUS Access-Challenge

RADIUS Scenario 2 (cont.) l 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 l The Authentication Server sends a RADIUS Access-Challenge packet which is forwarded to the client in the form of a CHAP Challenge l The client responds using the normal CHAP method l The rest of the procedure follows Scenario 1

Notes on RADIUS Scenarios 1 and 2 l Why use one method or the other? l In some cases, the Authenticator is programmed to take a load off the Authentication Server and will provide the CHAP Challenge itself l 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 l 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.

RADIUS message types: §  Access-Request. Sent by a RADIUS client to request authentication and authorization for a network access connection attempt. §  Access-Accept. Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized. §  Access-Reject. Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized. §  Access-Challenge. Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response. §  Accounting-Request. Sent by a RADIUS client to specify accounting information for a connection that was accepted. §  Accounting-Response. Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message.

Reference §D. Denning, P. Denning, Certification of Programs for Secure Information Flow, CommACM, V20 N7, Jul 1977, pp. 504-513 §J. Linn, Practical Authentication for Distributed Computing, Proc IEEE symp Security & Privacy, IEEE Comp Soc Press 1990, pp. 31-40 §C. P. Pfleeger, Security in Computing, Prentice Hall, NJ, 1996

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data* (variable) | ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable) | ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPSec Authentication l RFC 2401 and 2406 l IPSec works at layer 3 of the OSI model to create secure tunnels l Each encrypted packet in the tunnel contains authentication data to prove its origin End-to-end Node-to-node

IPSec protocol types §IPSec has two types §Transport mode: provides protection primarily for upper layer protocols, and is used for end to end communication between two hosts § Tunnel mode: provides protection to the entire IP packet.

Transport mode §Transport mode provides the protection of an IP payload through an AH or ESP header. Typical IP payloads are TCP segments (containing a TCP header and TCP segment data), a UDP message (containing a UDP header and UDP message data), and an ICMP message (containing an ICMP header and ICMP message data).

Authentication Header transport mode §Authentication Header transport mode §Authentication Header (AH) provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet). It does not provide confidentiality, which means that it does not encrypt the data. The data is readable, but protected from modification. AH uses keyed hash algorithms to sign the packet for integrity.

§For example, Alice on Computer A sends data to Bob on Computer B. The IP header, the AH header, and the data are protected with integrity. This means Bob can be certain it was really Alice who sent the data and that the data was unmodified. §Integrity and authentication are provided by the placement of the AH header between the IP header and the IP payload

Encapsulating Security Payload transport mode §Encapsulating Security Payload (ESP) provides confidentiality (in addition to authentication, integrity, and anti-replay) for the IP payload. ESP in transport mode does not sign the entire packet. Only the IP payload (not the IP header) is protected. ESP can be used alone or in combination with AH. §For example, Alice on Computer A sends data to Bob on Computer B. The IP payload is encrypted and signed for integrity. Upon receipt, after the integrity verification process is complete, the data payload in the packet is decrypted. Bob can be certain that it was Alice who sent the data, the data is unmodified, and no one else was able to read it.

Virtual private networking with IPSec §Tunneling is the entire process of encapsulation, routing, and decapsulation. Tunneling wraps, or encapsulates, the original packet inside a new packet. This new packet might have new addressing and routing information, which enables it to travel through a network. When tunneling is combined with data confidentiality, the original packet data (as well as the original source and destination) is not revealed to those listening to traffic on the network. The network could be any internetwork: a private intranet or the Internet. After the encapsulated packets reach their destination, the encapsulation is removed and the original packet header is used to route the packet to its final destination. §The tunnel itself is the logical data path through which the encapsulated packets travel. To the original source and destination peer, the tunnel is usually transparent and appears as just another point-to-point connection in the network path. The peers are unaware of any routers, switches, proxy servers, or other security gateways between the tunnel’s beginning point and the tunnel’s end point. When tunneling is combined with data confidentiality, it can be used to provide a virtual private network (VPN).

SSL and TLS l RFC 2246 l SSL is Secure Socket Layer Developed by Netscape for secure web transactions l TLS is Transport Layer Security Developed by IETF to have an open standard similar to SSL l They are essentially the same, with minor differences l Both rely on use of digital certificates and PKI

TLS/SSL Scenario 1 Hello Change connection state ClientServer Hello Client Certificate Server Certificate Request client Certificate Client Key Exchange Certificate Verify

TLS/SSL Scenario 1 l Both the Server and the Client use certificates l Examples: Secure exchange of electronic data between two servers Very secure organizational network where each user gets issued a certificate

TLS/SSL Scenario 1 l A Hello message is sent by the Client to notify the Server. The Hello message contains information about the protocols to be used for encryption and authentication. l The Server replies with its own Hello message confirming that it supports the protocols asked by the Client Hello messages contain randomly-generated numbers to assure liveness The Server Hello message contains an ID which will be used to match the responses to the requests l The Server sends its certificate to the Client, signed by a CA l The Server also sends a certificate request to obtain the Client’s certificate l After confirming that the Server certificate is valid, the Client sends its own certificate to the Server l A Key Exchange value is sent by the Client. This value is encrypted using the Server’s public key to prevent eavesdropping. This value will be used by both sides as a seed to compute a symmetric secret key between Client and Server l The Certificate Verify message is sent by the Client to further prove its identity It consists of a hash of all the messages sent and received so far, signed with the client’s secret key

TLS/SSL Scenario 2 Hello Change connection state ClientServer Hello Server Certificate Client Key Exchange Server Challenge Client Response Server Authentication Client Authentication

TLS/SSL Scenario 2 l Only the Server uses a certificate l The Client is authenticated by the server using an encrypted password technique l Examples: Web e-commerce transactions Web banking

Kerberos Scenario part 1 l Client and server share a secret key l The user enters a password which is encrypted using the secret key l The ticket-granting ticket (TGT) is an encrypted document similar to a certificate It is encrypted using the secret key It contains data to establish a session key for later communications with the KDC Request Ticket, I am “A”, encrypted password Client Key Distribution Centre (KDC) Encrypted Ticket-Granting Ticket Authentication Service (AS)

Kerberos Scenario part 2 l Client request a ticket to use C services l The ticket-granting service (TGS) verifies the validity of the TGT and issues a ticket for C The ticket is encrypted using the session key derived in step 1 It contains a part only decipherable by C l A will now present the ticket to C which will grant access to resources Request Ticket for C, this is my TGT Client Key Distribution Centre (KDC) Encrypted Ticket for C Ticket Granting Service (TGS) File or print service Ticket for C

Notes on Kerberos l The method is widely used and supported by manufacturers such as Microsoft l The method can be susceptible to a dictionary attack since every subsequent step relies on the user entering the password in the first place l Kerberos is not only Authentication but also Authorization A request for a resource may be denied, even if a user is valid Based on policies in place

Conclusion §Authentication is another critical step in security l Separates the “good guys” from the “bad guys” l If authentication is performed or bypassed by an attacker, the attacker will be considered by the system as a “good guy” Very difficult to identify and expel l Must be performed at the beginning of a transaction and subsequently at regular intervals l Has mechanisms to prevent attacks: Replay attacks Password attacks (dictionary, brute-force) §As security administrators, NEVER rely on authentication alone Part of a greater security policy Use authorization and intrusion detection

AUTHONTICATION. User Authentication §Use of Passwords §Attacks on Passwords §Password Selection Criteria §The Authentication Process §Flaws in the Authentication.

Similar presentations

Presentation on theme: "AUTHONTICATION. User Authentication §Use of Passwords §Attacks on Passwords §Password Selection Criteria §The Authentication Process §Flaws in the Authentication."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

AUTHONTICATION. User Authentication §Use of Passwords §Attacks on Passwords §Password Selection Criteria §The Authentication Process §Flaws in the Authentication.

Similar presentations

Presentation on theme: "AUTHONTICATION. User Authentication §Use of Passwords §Attacks on Passwords §Password Selection Criteria §The Authentication Process §Flaws in the Authentication."— Presentation transcript:

Similar presentations

About project

Feedback