Transcript Identification and Authentication

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.