Chapter 7 - Authentication 1. Verification of the claimed identity of an entity:

1. Chapter 7 - Authentication 1. Verification of the claimed identity of an entity: A person (e.g., the user of a system) or A system (e.g., a particular computer). 2. Verification that the contents of a file have not been altered: Since the file was initially authenticated and stored, or Since the file was initially authenticated and transmitted. Authentication & Hash Functions

2. Chapter 7 – Authentication of a User Obtain an identifier (name/address) and an authenticator (token, password, biometric) from the subject user/system. Compare the authenticator to the stored or computed information associated with the entity being authenticated. Determine that the authenticator presented and the stored or computed authenticator are the same. Authentication & Hash Functions

3. Password Authentication Widely used user authentication with a significant range of capabilities, strengths, and weaknesses. Login Prompt User Login Process Login Response Password File Y N Compare OK User id Password Reject User 1 User 2 User 3 . . . User n Zionko dorkum Alice . . . gee9me < User 2, dorkum > Authentication & Hash Functions

4. Login Process During a boot process or at a command line prompt, the operating system runs a login process that prompts the user: System challenge: Please Login User Response: <User_Identifier, Password> < > denotes user entered information The user_identifier is used as an index into a password file that holds valid user names and password pairs. Authentication & Hash Functions

5. Login Process The password returned from the file is compared to the password entered by the user and on a match, the user is authenticated and granted access to the system. The user is authorized to use the resources that are defined in the user’s profile for the system. How secure is this process and how can it be compromised? These issues were briefly discussed in Chapter 2. Authentication & Hash Functions

6. Password Security The main advantage of password systems are their ubiquity and ease of use. Potential problems are: 1. Composition of the password (too few symbols). 2. Length (too short). 3. Lifetime (too long). 4. Source (if simply generated may be simply broken). 5. Ownership/Sharing (you own it, don’t share it). 6. Initial generation/distribution (is it well protected?). 7. Storage (there for all to see?). 8. Transmission (in the clear – can it be sniffed?). Authentication & Hash Functions

7. Password Security Factors Composition:The password symbol set. Typically: 10 numeric digits for ATM PINs (personal id number). 95 printable ASCII symbols for computers (varies). Users can construct many combinations, strong or weak. Particularly unacceptable are: Dictionary words and permutations (e.g., backwards). Personal names/dates (e.g., wife, pets, birthdays, etc.). All alpha or all numeric (use mixed). Single case (use mixed case). Authentication & Hash Functions

8. Password Security Factors Length:Composition & length establish the difficulty in brute force attacks (exhaustive search) on passwords. Using 95 characters and length (L) = 1 implies only 95 possible passwords. The password search space is: N = SL; where: N = # of possible passwords S = # of symbols (characters) in the password alphabet L = Length of the password in symbols For S = 95, L = 7; N = 957 ~ 7 x 1013 Authentication & Hash Functions

9. Password Security Factors On average, an attacker would have to attempt 1/2 of the possible passwords to find the right one. If passwords can be attempted at 106, 107, and 108 per second. Then: Time 1000 = ((7 x 1013)/(106))(1/60x60x24) = 810.2 days Time 100 = ((7 x 1013)/(107 sec))(1/60x60x24) = 81 days Time 10 = ((7 x 1013)/(108 sec))(1/60x60x24) = 8.1 days Times are all within the capability of modern systems, especially parallel machines. The times are even faster if the password is not randomly constructed and/or does not use the full character set (i.e. has low entropy). Authentication & Hash Functions

10. Password Security Factors Lifetime:Passwords should have a limited valid lifetime. Ideally, they should be one-time passwords that are only valid for a single use (change with every use). If persistent, then valid lifetimes are based on a balance between the threat and time-value of the information being protected. Times ranges are 3-12 months (6 months typical), more often for system administrators. They should be changed after 1st issued or when compromised/shared. Authentication & Hash Functions

11. Password Security Factors Source: Passwords should be algorithmically generated by a computer where the algorithm has been tested against known hacking tools (e.g., CRACK, l0phtcrack). If algorithmically generated, several should be presented To the user for selection. If user generated, they should be tested for strength before being allowed (assuming this capability is available). Authentication & Hash Functions

12. Password Security Factors Ownership:A password belongs to a single individual and should never be shared. A shared password is, by definition, a compromised password. If sharing is essential (e.g., a temporary secretary), change it immediately after sharing is over. Distribution: Passwords should be distributed in a secure manner with positive identification of the user (to avoid social engineering or other masquerades). Authentication & Hash Functions

13. Password Security Factors Storage: Passwords appear in at least two places; stored on systems and passed over the network. Two threats are obvious: Unauthorized disclosure and Unauthorized replacement The first is rather obvious, but if an adversary can replace a password, they can masquerade as a legitimate user. Authentication & Hash Functions

14. Password Security -Transmission Password designs in order of increasing protection: Clear text passwords - threat is sniffing. Any system with access to the transmission channel can run a network interface in promiscuous mode and read every password flying by or any directed to the system the sniffer is installed on. Encrypted passwords - threat is capture, off-line cracking, and/ or re-play at a later time. Authentication & Hash Functions

15. Password Security -Transmission Hashed passwords - threat is capture, off-line guessing, and/or re-play - harder than dictionary attacks - requires generation of passwords, hash, and compare. Hashed with a random number - same as hashed, but more difficult to guess (longer, more random source). One-time hashed or encrypted – used once and changes with every subsequent use - most secure. Authentication & Hash Functions

16. Password Security – Storage Protection Methods • Storage in the order of increasing protection are: • Password stored in clear text in the system • administrator account (requires privilege to see). • 2. Password stored in clear text in an account only • accessible by the login or password management • process (no administrator access). • 3. Password is encrypted and stored in a publicly • accessible file (Unix originally did this). • 4. Password is encrypted and stored in a file only • accessible by a system administrator (current Unix). Authentication & Hash Functions

17. Password Security – Storage Protection Methods 5. Password hashed and hash stored, not password. 6. One-time hashed password - as in transmission – best method Clear text passwords stored or transmitted are extremely vulnerable. A network sniffer can capture transmitted passwords. A privileged user (e.g., system administrator) can read the file. Authentication & Hash Functions

18. Passwords - Clear Text Transmission & Storage Authentication & Hash Functions

19. Encrypted Password Protection Login process encrypts password entered by the user and compares it to the encrypted value, on match the user is authenticated. The password itself is never stored. Variation 1: Two-way (reversible) encryption, public file. The password is encrypted and stored in a public file. Login process encrypts the password using the user_name or a fixed number as the key and compares the stored value with the user supplied value. Any user can get the file and perform an off-line attack using the standard encryption and a dictionary (encrypt the dictionary words, search for a match. Will returns breaks in seconds, minutes or a few hours. Authentication & Hash Functions

20. Passwords - Encrypted Storage Attack Authentication & Hash Functions

21. Encrypted Password Protection Variation 2: Encrypt and store in a non-public file accessible only to the system administrator. In this case, an adversary must not only gain access, but must also gain system administrator (root) access. Better, but many systems have been compromised by attacks where the adversary gains root privileges. There are many root kits out on the Internet. In either variation 1 or 2, the encryption key must be protected. Authentication & Hash Functions

22. Encrypted Password Protection Variation 3: One-way (non-reversible) hash where the password is not stored. Only the hash is stored. A hash is a one-way transform that is infeasible to invert. A password manager creates a hash of the user’s password and stores it. When a user logs in, the same hash algorithm creates a new hash on the user supplied password and it is compared to the stored hash value. A hash can be a keyed or keyless transform. In this case, the key is the password and it is never stored. Authentication & Hash Functions

23. Unix Passwords Unix standard for 30 years is the crypt() function. crypt() uses a modified form of the DES algorithm operating like a hash. Also uses a “salt” that is a random number so two user’s passwords do not produce the same hash. The salt is a 12-bit random number derived from the system clock when the password is created. The password is 8 characters in length (56 bits) combined with the salt and used as the DES key. Authentication & Hash Functions

24. Unix Passwords The algorithm performs 25 encryptions and produces an 11 character output. The output is stored along with the 12-bit salt. On login, the salt is accessed, combined with the password, the encryption is run, and the output compared to the 11 character stored value. The password part of the key is not stored; only the salt is stored. Still a persistent password and crypt() is no longer Considered a strong algorithm. Authentication & Hash Functions

25. Crypt Breaks Assuming 95 characters and length = 8: N = SL = 958 ~ 6.6 x 1015 possible encryptions (hashes). The San Diego Supercomuter Center (SDSC) mounted an attack on crypt by pre-computing the hashes on 207 B hashes for over 50 million of the most common passwords in 80 minutes. While that is only .003% of the possible passwords, they are the most common so they represent a much higher percentage of “real” passwords. Authentication & Hash Functions

26. Crypt Conclusions The time required to break crypt is tractable and even better with faster cpus. The storage required to hold results is tractable at about 1.5 terabytes. SDSC concludes that crypt is no longer adequate. Reference: http://security/sdsc/edu/publications/ teracrack.pdf Authentication & Hash Functions

27. One-Time Password - Lamport’s Method Used for remote login to a server or network so there are two sides, client/server. The client enters a passphrase. Servers maintain a database of: client username, integer n that decrements for every login, and a hashn(passphrase). hashn = hash(hash(hash(hash….hash(passphrase)…)). The user chooses a passphrase and a number n (1 < n < 1000) and computes m1 = hash(passphrase), m2 = hash(m1), … n times to produce mn = hashn(passphrase). The server stores this value. Authentication & Hash Functions

28. One-Time Password - Lamport’s Method The client sends the server n and mn = hashn(passphrase). To login from the client to the server, the client prompts the user for a username and the passphrase. The username is sent to the server. The server response returns the current value of n, say 100. This value is decremented after every use. The workstation computes hashn-1(passphrase) and sends the result to the server. Servers accepts hashn-1(passphrase) and hashes it once more producing hashn(passphrase) and compares it to the stored value for the user. Authentication & Hash Functions

29. One-Time Password - Lamport’s Method On match, the user is authenticated. The received value, the hashn-1 (passphrase), is used to replace the current value hashn(passphrase) on the server and n is decremented. Next login, n = n-1 is passed and the hash is different. This is a one-time password that can’t be re-played by an adversary. Further, the passphrase is never disclosed over the connection between the client and the server. Authentication & Hash Functions

30. Lamport’s Method - Example ClientServer Setup: Select username, n = 100, and passphrase Compute hash100(passphrase) Send username, n, hash to server -------- Store username, n, hash First use: Username login request sent to server -- Get n, compute n-1 (99), save, return 99 to user Enter passphrase, compute hash99, send to server ----------- Compute hash99+1, compare to original stored hash Next use (hash98) and so on Result is a one-time password, never sent in the clear! Authentication & Hash Functions

31. Lamport’s Method - Enhanced If n reaches 1, a new password must be selected and the hash re-initialized. This makes life more difficult for the user. So.. we add a salt, a random number that is concatenated with the passphrase to produce hashn(passphrase|salt). Now n, the salt, and the hashn(passphrase|salt) is sent to the server. On login request, the server returns the current n, and the salt. Authentication & Hash Functions

32. Lamport’s Method - Enhanced The benefit is the same passphrase can be used on several systems, each with a different salt. When n reaches 1 and a new hash must be generated, the passphrase can be re-used with the new salt. The salt prevents an adversary from pre-computing hashn for dictionary words and values of n from 1 to n, then accessing the server database, and comparing hashes with the stolen passphrase hashes. Authentication & Hash Functions

33. Lamport’s Method - S/Key S/key is an extension of the Unix “salt” method using Lamport's algorithm and is used on most Unix systems. Generates multiple hashes, each with an iteration count so no two are alike. Each hash is good for a single login S/Key Consists of four processes: ‘Key’ ‘Keyinit’ ‘Keyinfo’ ‘login & su’ Authentication & Hash Functions

34. Lamport’s Method - S/Key ‘Key’ uses an iteration count, a salt (called a seed), and a secret passphrase and generates a one-time password hashed n times, where n is the iteration count. ‘Keyinit’ initializes and change passwords, iteration counts, & seeds. ‘Keyinfo’ returns the current iteration count & seed. ‘login & su’ contain code to recognize S/key passwords. Authentication & Hash Functions

35. S/Key - How It Works Seed is generated by the client and is 2 letters and 5 digits (e.g., ba65867). A secret passphrase is entered by the user (e.g., a six-word phrase - like GRP DEOS BUND CHAO SEEN NEEP). An iteration count from 1-100 is entered (user selected and determines the number of hash rounds to apply). The hash is generated by concatenating the seed and the passphrase, using an MD5 hash. The number of times the hash is applied is = iteration count. Authentication & Hash Functions

36. S/Key - How It Works The one-way function results are significantly different between each iteration - knowing one will not aid in predicting the next one (e.g., by intercepting one logon). The environment you generate the password on (usually the client machine) must be secure. If a local client - no sniffers. Must have a secure connection if the local client can’t do this computation (e.g., an X-terminal). Authentication & Hash Functions

37. One-Time Password - S/Key There is now a password stored on your machine (the pass phrase is not). You must get the password to the server. Run “keyinit” on the server. Enter the seed and iteration count used, copy the hash generated on your secure machine to the host. The secret passphrase is never disclosed on the connection. Only the seed, iteration count, and hash password have been sent to initialize/synch the the server to the client. Authentication & Hash Functions

38. One-Time Password - S/Key An adversary could intercept communication and get the seed, iteration count, and hash, but this is not enough to predict the next hashed password. Authentication & Hash Functions

39. One-Time Password - S/Key - Key & Keyinit Client Side Server Side Username, Salt Username, Salt, Count File Hash Iteration Count Pass- word file Secret Passphrase (not stored, not passed, system must be secure when entered - no internal sniffer) Client password for a specific hash count Authentication & Hash Functions

40. One-Time Password - S/Key - Key & Keyinit Client Side Server Side Login Process Username Username, Salt, Count File Login Request Salt, Count Secret Passphrase Compute new hash (for current iteration count) Verify (compute hash n) Pass- word file Password Hashed password for a nth iteration count Authentication & Hash Functions

41. Microsoft Passwords In a networked environment, users are authenticated to a domain controller using a password. Originally this Service was called LANMAN and relied on short Passwords that were not very strong. Windows NT supports 14 character passwords to increase strength (~ 5 x 1033 possibilities for a 256 character symbol set). Limitations: Can’t use all the characters (duh!). Not everyone uses 14 character passwords. They may pick easy passwords (if no enforcement capability). So what..? Authentication & Hash Functions

42. Microsoft NT Passwords It gets worse because of the form of the stored password. To support backward compatibility with LANMAN, NY stores the passwords as MD4 hashes (good) as two 7-character passwords (bad). It is only about twice as difficult to find a 14 character password that produces a specific hash (guess a 7 bit partial password and compute the hash) than it is for only a 7 bit password alone. This will be OK when LANMAN goes totally away. Authentication & Hash Functions

43. Kerberos Authentication Kerberos is an authentication protocol named for the watchdog of Greek mythology that guarded the gates of Hades. The dog is depicted with three heads, a serpent’s tail, a mane of snakes, and a lion’s claws (makes you wonder who is guarding the exit!). First developed in the 1980’s, maintained, and distributed by MIT originally for Unix systems – also now used in Windows 2000 & XP. Specifications are open – code is another matter (there are many different instances). Authentication & Hash Functions

44. Kerberos Authentication Kerberos is a authentication protocol for client/server applications (usually remote logins) - also supports message integrity and data confidentiality. Kerberos uses symmetric key encryption which generally doesn’t support authentication. Kerberos is the exception to this observation. Kerberos supports two primary service mechanisms – a key distribution service and a ticket-granting service. Authentication & Hash Functions

45. Kerberos Authentication - Example Alice and Bob (Bob is usually a remote service rather than a person). Alice wants to establish mutually secure authentication and send and receive secure messages. A Kerberos Key Distribution Server (KDS) manages and distributes the keys for Alice and Bob and supports a Ticket Granting Service (TGS) that issues time-dependent tickets to Alice and Bob for secure authentication and communication. This is a three-headed system with two principals (Alice & Bob) and a trusted third party, the KDS. Authentication & Hash Functions

46. Kerberos Initialization Requires a Kerberos-enabled client and enrollment in the KDS (sometimes called a KDC (Center). Once a user is enrolled, the KDC creates a database entry for the user that contains a long term key for each user based on the users-name. The key is derived by creating a one-way hash of the user’s password. This is one of the potential vulnerabilities of Kerberos if the user selects a poor password! (see Stallings pg. 415-416 for details). Authentication & Hash Functions

47. Kerberos Initialization The long term key is stored on the KDC, but is not stored on the user’s system. It is re-created each time it is needed. This can create some difficulties when users change their passwords so it is not a good idea to use the same password on other systems. For Alice to authenticate to Bob, she presents her password to the local Kerberos client and it accesses the KDC. Authentication & Hash Functions

48. Kerberos – Authentication Request Alice’s client sends a Ticket-granting Ticket request to the KDC indicating she is an authorized user. It contains both names, Alice and Bob and is DES encrypted with Alice’s password-derived key. Alice’s Ticket-Granting Ticket, Request to authenticate to Bob, Contains Alice’s username and Bob’s name – encrypted with Alice’s long term DES key. Alice KDC Authentication & Hash Functions

49. Kerberos – KDC Response to Alice Alice’s client sends an application request to Bob that contains the ticket provided by the KDC containing Alice’s name, the session key, and expiry time all encrypted with Bob’s long term key and An authenticator encrypted with the session key. Bob decrypts the ticket finding Alice, time, and the session key and uses the session key to decrypt the authenticator – knows Alice knows the session key. Bob checks the time to see if it is valid. At this point Bob has authenticated Alice. Alice Bob Authentication & Hash Functions

50. Kerberos – Bob’s Response to Alice Bob adds one to the time Alice sent, encrypts it with the session key and sends it back to Alice. Alice decrypts with the session key and checks the time to see if the time is her time plus one. At this point Bob has authenticated to Alice. From this point on Alice and Bob can exchange Messages. Alice can log on to Bob and use service. Alice Bob Authentication & Hash Functions