Unformatted text preview:

Chapter 9. Overview of Authentication SystemsPassword-based AuthenticationIt's not who you know. It's what you knowOn-line Password attack:Easy to defend, limit and slow down the number of guesses.Off-line Password attack:Capture a quantity X derived from the password and take your time to guess (e.g., use a dictionary) the password that produces X.Storing User Passwords:o Store password hashes.o Encrypt the password database and safeguard the encryption key.o Combination: Encrypt the database of hashed passwords.Address-based AuthenticationIt's not what you know. It's where you areIn Unix implementations:/etc/hosts.equiv:Contains a list of computers that have identical user accounts.allow users on these hosts to login (rsh) without providing passwords.$HOME/.rhosts:e.g., if at cs.unc.edu file /home/wahab/.rhosts contains:isis.cs.odu.edu wahabisis.cs.odu.edu wildallows wahab and wild to login as wahab to any host at cs.unc.edufrom host isis.cs.odu.edu (wild does not know wahab's password).(see % man hosts.equiv for details). The /etc/hosts.equiv and .rhosts files provide the "remote authentication" database for rlogin(1), rsh(1), rcp(1), and rcmd(3SOCKET). The files specify remote hosts and users that are considered "trusted". Trusted users are allowed to access the local system without supplying a password. The library routine ruserok() (see rcmd(3SOCKET)) performs the authentication procedure for programs by using the /etc/hosts.equiv and .rhosts files. The /etc/hosts.equiv file applies to the entire system, while individual users can maintain their own .rhosts files in their home direc- tories. These files bypass the standard password-based user authentication mechanism. To maintain system security, care must be taken in creating and maintaining these files. The remote authentication procedure determines whether a user from a remote host should be allowed to access the local system with the identity of a local user. This procedure first checks 1the /etc/hosts.equiv file and then checks the .rhosts file in the home directory of the local user who is requesting access. Entries in these files can be of two forms. Positive entries allow access, while nega- tive entries deny access. The authentication succeeds when a matching positive entry is found. The procedure fails when the first matching negative entry is found, or if no match- ing entries are found in either file. The order of entries is important. If the files contain both positive and nega- tive entries, the entry that appears first will prevail. The rsh(1) and rcp(1) programs fail if the remote authentication procedure fails. The rlogin program falls back to the stan- dard password-based login procedure if the remote authenti- cation fails. Both files are formatted as a list of one-line entries. Each entry has the form: hostname [username]Possible Threats: (1) When a node is compromised, not only are its resources compromised, but also all other systems’ resources that have the users on the compromised system in their .rhosts file.(2) If an intruder can impersonate a network address, it can cause damage on all systems that have this system and its users in their .rhosts file.Network address Impersonation:Generally, it is not difficult for Trudy to claim Alice's address as the source address, but itis more difficult for Trudy to receive messages addressed to Alice's network address.In IP protocol, Trudy may use source routing to achieve that by sending amessage with source route: <Alice, Trudy, Dist> and Dist will reply with source route:<Dist, Trudy, Alice> Thus Trudy can get the reply!Cryptographic Authentication Protocols“Alice proves her identity to Bob by performing a cryptographic operation on a quantity Bob supplies.”Who is being authenticated?(1) The user (2) Machine (3) Both Impact: Machines can store very long passwords; humans can’t.Passwords as Cryptographic Keys:2Main issue: How to convert the human memorizable password into a machine generated secret key and/or private key.To convert a text string memorable by a human e.g., oducsc, into cryptographic secret key, e.g., DES key, do a cryptographic hash of the password and take the 56 bits of the result. This secret key can also be used to encrypt/decrypt a private key (e.g.,RSA private key) saved in a file.Eavesdropping & Server Database ReadingPublic Key Cryptography:Makes it easy to perform authentication that both:Secure against eavesdropping &Protects against an intruder reading the server database.Alice BobI am Alice -----> Bob knows Alice’s public key: eR <----- R (random)sign R: X = [R]d -----> verify: R = [X]ePassword Hashing:Alice BobI am Alice, oducsc ---> knows hash of Alice Pwd, hcheck that: h = MD(oducsc)Problem: eavesdropping.Shared Secret:Alice BobI am Alice ------> get Alice secret key: KR <----- R (random)encrypt R: X = K{R} -----> decrypt: R = K[X]Problem: reading the server database.Trusted IntermediariesIf we have N nodes:If each nodes keeps N-1 secrets, then adding a new node involves adding N new secrets, one at each node. Clearly not practical for large N.Solution: KDC (Key Distribution Center):KDC knows N keys, one for each node. Adding a new node involves only adding one key at KDC.If Alice likes to talk to Bob:Alice  KDCNeed to talk to Bob ---> Authenticate Alice and generate a random# RabTicket: KB(Rab, Alice, …} = KA[X] <--- X= KA{KB(Rab, Alice, …})Ticket---> Rab= KB(Ticket)C1 = Rab{M1} ---------------------> M1 = Rab[C1]3M2 = Rab[C2] <--------------------- C2 = Rab{M2}Disadvantages of KDC:If compromised, all Keys are compromised.Single point of failurePerformance bottleneck.CA (Certification Authority):Each node keeps its private key.The CA certifies (sign) that the public key belong to the node and everyone trustthe CA that he checked this fact for each node.All public key certificates may be kept in one place or each node keeps its owncertificate and presents it to whoever asks for it.Certifies expire after a reasonable period (e.g., 1 year) but can be revoked at anytime and the CA periodically publish a CRL (certificate revocation list) thatcontains all the revoked certificates.Clients should check the latest CRL


View Full Document

ODU CS 772 - Lecture Notes

Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?