1. Identification and Authentication University of Sunderland COM380 Harry R. Erwin, PhD

2. I&A Introduction Purpose: to identify a user to the system To authenticate someone, at least one of the following factors must be supplied: –Something known (user name and password) –Something owned (password token) –Some physical characteristic (fingerprint, retinal scan, voice scan) Authentication is weak if only one is supplied. Two are required for strong authentication.

3. E-Commerce and Authentication To have the flexibility of money, I&A should not be required until a purchase is made. You can require the user to log into your site, but most authentication schemes are very weak. You will be liable if the user data escapes due to weak authentication. (Risk!) SSL authenticates the web site to the user, not the user to the web site. The user authenticates herself by providing credit card details. Consider paying a third party to handle this.

4. Passwords Local login –Provide a user ID –Then provide a password Remote logins are similar –telnet, rlogin, rsh, ssh (terminal sessions) –ftp, ncftp, sftp, rcp, scp (file transfer) Avoid telnet, ftp, ncftp, rlogin, rsh, and rcp. They transmit I&A data in the clear.

5. Implementing Passwords Do not store passwords in the clear. Store the encrypted password and compare to that. Password files should not be accessible to users. Hackers can run ‘crack’ against them in a dictionary attack. Consider running ‘crack’ regularly against your own password file. UNIX provides a ‘salt’ field in the password file unlike Windows. This is concatenated with the password before encryption (using DES), increasing the search space for ‘crack’.

6. Good Password Policies 6 or more characters Change every 30-60 days Passwords must be used for at least 2-7 days Previous passwords cannot be reused. Three+ different character types (upper case, lower case, numbers, symbols) Avoid weak passwords (names, addresses, phone numbers, SSNs, common dictionary words or phrases, and simple variations on the above).

7. An Approach to Choosing Stronger Passwords (Suggested by Qinetiq.) Start with a phrase about a date. Use the initials, lower case and upper case alternating. Insert a special character somewhere. Remember September 11th, 2001! rS1101! My birthday is February 29th! mBiF29!

8. Tokens Rather than something you know (password), you provide something you own. The usual approach is that you provide an identifier (the first factor), and The system then sends you a challenge that you respond to (the second factor). The response is generated by a device that you keep in your possession.

9. Biometrics The system identifies you by something you are: –Fingerprint(s) –Retina pattern –Iris pattern –Facial pattern –Voice Demands good and expensive technology.

10. Handling Special Requirements (Example) FAA system administrators at an enroute control center work as a team, under the supervision of a NAS Operations Manager (NOM). Logging in would disrupt teamwork and delay response to emergencies. Hence I&A is handled procedurally, except at terminals away from the central operations area. In the central operations area, the team logs in using a team ID and password that is only good there. Elsewhere individual ID/PW are required.

11. FIA—CC User Identification and Authentication Functions FIA_AFL –How do you handle a login failing (possibly repeatedly)? FIA_UID –How does a user identify herself? –What actions may an unidentified user take? FIA_SOS –Do you generate passwords or other secrets for the user? –If not, do you test user-provided passwords or other secrets for strength?

12. CC User Authentication Functions FIA_UAU –What user actions do you allow before the identified user must authenticate herself? –How many authentication mechanisms are used? –What are the authentication mechanisms? –Under what conditions must the user reauthenticate herself? –How does the system avoid letting the user know why ID and authentication failed?

13. Miscellaneous CC I&A Functions FIA_ATD –What security attributes are associated with the individual? FIA_USB –Does the system associate user actions with user identity? FTA_TSE –What factors (access port, ID, user location) affect whether a user is allowed to establish a session?

14. More Miscellaneous CC I&A Functions FTA_TAH –Does the system report an access history to the user at session establishment? FTP_TRP –Is there a trusted path between the user and the system? Can it be enforced? AGD_ADM –Administrator guidance documentation. AGD_USR –User guidance documentation.

15. Conclusions Strong authentication is desirable. Costs are significant. Not really compatible with e-commerce. Vulnerable to social engineering and the general public availability of private data.