Identification and Authentication

University of Sunderland

COM380

Harry R. Erwin, PhD

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.

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.

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.

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

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

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!

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.

Biometrics

• The system identifies you by something you are:– Fingerprint(s)– Retina pattern– Iris pattern– Facial pattern– Voice

• Demands good and expensive technology.

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.

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?

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?

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?

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.

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.