Identity Management Basics Passwords Challenge-Response

Overview • Basics • Passwords – Storage – Selection – Breaking them • Other

Basics • Authentication: binding of identity to subject – Identity is that of external entity (my identity, Matt, etc. ) – Subject is computer entity (process, etc. ) November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 3

Establishing Identity • One or more of the following – What entity knows (eg. password) – What entity has (eg. badge, smart card) – What entity is (eg. fingerprints, retinal characteristics) – Where entity is (eg. In front of a particular terminal) November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 4

Authentication System • (A, C, F, L, S) – A information that proves identity – C information stored on computer and used to validate authentication information – F complementation function; f : A C – L functions that prove identity – S functions enabling entity to create, alter information in A or C November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 5

Passwords • Sequence of characters – Examples: 10 digits, a string of letters, etc. – Generated randomly, by user, by computer with user input • Sequence of words – Examples: pass-phrases • Algorithms – Examples: challenge-response, one-time passwords November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 6

Storage • Store as cleartext – If password file compromised, all passwords revealed • Encipher file – Need to have decipherment, encipherment keys in memory – Reduces to previous problem • Store one-way hash of password – If file read, attacker must still guess passwords or invert the hash November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 7

Example • UNIX system standard hash function – Hashes password into 11 char string using one of 4096 hash functions • As authentication system: – – – A = { strings of 8 chars or less } C = { 2 char hash id || 11 char hash } F = { 4096 versions of modified DES } L = { login, su, … } S = { passwd, nispasswd, passwd+, … } November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 8

Attacks • Trial-and-error from a list of potential passwords – Off-line: know f and c’s, and repeatedly try different guesses g A until the list is done or passwords guessed • Examples: crack, john-the-ripper – On-line: have access to functions in L and try guesses g until some l(g) succeeds • Examples: trying to log in by guessing a password November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 9

Preventing Attacks • How to prevent this: – Hide c or increase the complexity of a • Prevents obvious attack from above • Example: UNIX/Linux shadow password files – Block access to all l L or result of l(a) • Place a limit on password failed attempts • Example: preventing any logins to an account from a network. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 10

Shadow File • Traditional Unix systems keep user account information, including one-way encrypted passwords, in a text file called ``/etc/passwd''. As this file is used by many tools (such as ``ls'') to display file ownerships, etc. by matching user id #'s with the user's names, the file needs to be world-readable. Consequently, this can be somewhat of a security risk. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 11

Shadow File • Another method of storing account information is with the shadow password format. As with the traditional method, this method stores account information in the /etc/passwd file in a compatible format. However, the password is stored as a single "x" character (ie. not actually stored in this file). A second file, called ``/etc/shadow'', contains encrypted password as well as other information such as account or password expiration values, etc. The /etc/shadow file is readable only by the root account and is therefore less of a security risk. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 12

Passwd File • With shadow passwords, the ``/etc/passwd'' file contains account information, and looks like this: • smithj: x: 561: Joe Smith: /home/smithj: /bin/bash. Each field in a passwd entry is separated with ": " colon characters, and are as follows: • Username, up to 8 characters. Case-sensitive, usually all lowercase • An "x" in the password field. Passwords are stored in the ``/etc/shadow'' file. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 13

Passwd File • smithj: x: 561: Joe Smith: /home/smithj: /bin/bash • Numeric user id. This is assigned by the ``adduser'' script. Unix uses this field, plus the following group field, to identify which files belong to the user. • Numeric group id. Red Hat uses group id's in a fairly unique manner for enhanced file security. Usually the group id will match the user id. November 1, 2004 Introduction to Computer Security 14 © 2004 Matt Bishop

Passwd File • smithj: x: 561: Joe Smith: /home/smithj: /bin/bash • Full name of user. I'm not sure what the maximum length for this field is, but try to keep it reasonable (under 30 characters). • User's home directory. Usually /home/username (eg. /home/smithj). All user's personal files, web pages, mail forwarding, etc. will be stored here. • User's "shell account". Often set to ``/bin/bash'' to provide access to the bash shell (my personal favorite November 1, 2004 shell). Introduction to Computer Security 15 © 2004 Matt Bishop

Shadow File • smithj: Ep 6 mckr. OLCh. F. : 10063: 0: 99999: 7: : : As with the passwd file, each field in the shadow file is also separated with ": " colon characters, and are as follows: • Username, up to 8 characters. Case-sensitive, usually all lowercase. A direct match to the username in the /etc/passwd file. • Password, 13 character hashed. A blank entry (eg. : : ) indicates a password is not required to log in (usually a bad idea), and a ``*'' entry (eg. : *: ) indicates the account has been disabled. November 1, 2004 Introduction to Computer Security 16 © 2004 Matt Bishop

Shadow File • smithj: Ep 6 mckr. OLCh. F. : 10063: 0: 99999: 7: : : • The number of days to warn user of an expiring password (7 for a full week) • The number of days after password expires that account is disabled • The number of days since January 1, 1970 that an account has been disabled • A reserved field for. Computer Security future use 17 possible November 1, 2004 Introduction to © 2004 Matt Bishop

Using Time Anderson’s formula: • P probability of guessing a password in specified period of time • G number of guesses tested in 1 time unit • T number of time units • N number of possible passwords (|A|) • Then P ≥ TG/N November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 18

Example • Goal – Passwords drawn from a 94 -char set – Can test 8 million guesses per second – Probability of a success to be 0. 01 over a 365 day period – What is minimum password length? • Solution – N ≥ TG/P = (365 24 60 60) 8 106/0. 01 = 252, 288 1011 – Choose s such that sj=0 94 j ≥ N – So s ≥ 6, meaning passwords must be at least 9 chars November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop long 19

Approaches: Password Selection • Random selection – Any password from A equally likely to be selected • Pronounceable passwords • User selection of passwords November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 20

Pronounceable Passwords • Generate phonemes randomly – Examples: helgoret, juttelon are; przbqxdfl, zxrptglfn are not • Problem: too few November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 21

User Selection • Problem: people pick easy to guess passwords – Based on account names, user names, computer names, place names – Dictionary words (also reversed, odd capitalizations, control characters, “elite-speak”, conjugations or declensions, swear words, Torah/Bible/Koran/… words) – Too short, digits only, letters only – License plates, acronyms, social security numbers – Personal characteristics or foibles (pet names, nicknames, job characteristics, etc. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 22

Proactive Password Checking • Analyze proposed password for “goodness” – Always invoked – Can detect, reject bad passwords for an appropriate definition of “bad” – Discriminate on per-user, per-site basis – Needs to do pattern matching on words – Needs to execute subprograms and use results • Spell checker, for example – Easy to set up and integrate into password selection system November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 23

Password Aging • Force users to change passwords after some time has expired – How do you force users not to re-use passwords? • Record previous passwords • Block changes for a period of time – Give users time to think of good passwords • Don’t force them to change before they can log in • Warn them of expiration days in advance November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 24

Challenge-Response • User, system share a secret function f (in practice, f is a known function with unknown parameters, such as a cryptographic key) request to authenticate system user random message r (the challenge) system user f(r) (the response) system user November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 25

One-Time Passwords • Password that can be used exactly once – After use, it is immediately invalidated • Challenge-response mechanism – Challenge is number of authentications; response is password for that particular number • Problems – Synchronization of user, system – Generation of good random passwords – Password distribution problem November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 26

Good Password Practices • Password length, complexity and change frequency must be commensurate with sensitivity of information accessed. • Minimum 8 character alphanumeric. • Regular users must change at least once every 90 days. • System Administrators must change at least once every 30 days. • Password owners must be able to change their own passwords. • Must not be shared with anyone else. • Login id must be suspended after 5 consecutive, failed password entry attempts. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 27

Good Password Practices • At point of entry, passwords must not be displayed on monitor but may be represented by special characters such as an asterisk. • Passwords must not be reused with 365 consecutive days. • Default vendor software passwords must be changed after first use. • • Key entry of password is required for every access attempt. Initial password must be changed after first use. • Passwords must not be stored or transmitted in plain text. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 28

Good Password Practices • Should not use dictionary words or common names or words or common acronyms. • • Should not use a common pattern, e. g. , incrementing each password generation by “ 1”. Should not write down passwords. • Should not communicate passwords by mail or plain text email. • • Challenge response required for remote password reset. Stronger control over administrator passwords. Emergency passwords should be changed after every use. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 29

Password Responsibilities • Everyone responsible for managing and safekeeping of individual passwords. • System administrators responsible for monitoring password use and administering irregular changes. • Managers responsible for ensuring staff understand responsibilities. • Systems developers responsible for ensuring systems require strong passwords. • Help Desk is responsible for assisting users during password changes. November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 30

Biometrics • Automated measurement of biological, behavioral features that identify a person – Fingerprints: optical or electrical techniques • Maps fingerprint into a graph, then compares with database • Measurements imprecise, so approximate matching algorithms used – Voices: speaker verification or recognition • Verification: uses statistical techniques to test hypothesis that speaker is who is claimed (speaker dependent) • Recognition: checks content of answers (speaker independent) November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 31

Other Characteristics • Can use several other characteristics – Eyes: patterns in irises unique • Measure patterns, determine if differences are random; or correlate images using statistical tests – Faces: image, or specific characteristics like distance from nose to chin • Lighting, view of face, other noise can hinder this – Keystroke dynamics: believed to be unique • Keystroke intervals, pressure, duration of stroke, where key is struck • Statistical tests used November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 32

Location • If you know where user is, validate identity by seeing if person is where the user is – Requires special-purpose hardware to locate user • GPS (global positioning system) device gives location signature of entity • Host uses LSS (location signature sensor) to get signature for entity November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 33

Multiple Methods • Example: “where you are” also requires entity to have LSS and GPS, so also “what you have” • Can assign different methods to different tasks – As users perform more and more sensitive tasks, must authenticate in more and more ways (presumably, more stringently) File describes authentication required • Also includes controls on access (time of day, etc. ), resources, and requests to change passwords – Pluggable Authentication Modules November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 34

Key Points • Authentication is not cryptography – You have to consider system components • Passwords are here to stay – They provide a basis for most forms of authentication • Protocols are important – They can make masquerading harder • Authentication methods can be combined November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 35

Personal Information Protection and Electronic Documents Act • Applies to federally regulated industries • Governs the collection, use and disclosure of personal information in a manner that balances the right of privacy of all individuals • Requires each organization to designate a responsible officer November 1, 2004 Introduction to Computer Security © 2004 Matt Bishop 36