• Readings – Chapters 9, 10 – Sections 11.1-11.3
1 Authentication: Who and How
• User (human) can be authenticated – logging into a workstation – using resources of a system – issues: humans find it difficult to remember arbitrary strings • Computer can be authenticated – computer providing one function wants to authenticate another computer providing a different function – issues: computers need to store any authentication information someplace • How is authentication done – password based – address based – cryptographic algorithms based – combinations of the above
2 Address-based Authentication
• A machine keeps a list of network addresses of equivalent machines – unix keeps this information in /etc/hosts.equiv • A machine keeps a list of remote users allowed to access an account on the local machine – unix has a file .rhosts (in the home directory) that a user can set. Suppose .rhosts in your home directory had a line: gryphon.csi.cam.ac.uk bob Then bob from gryphon could rlogin without a password • These are becoming legacy approaches as they are not very secure
3 Password-based Authentication
• User authenticates by entering a password -- this is checked against the server’s database – Pros: • Supported by almost every system • Users familiar with the process – Cons: • Good password management is crucial • Storing passwords securely can be a problem
4 ASCII Characters and Printing Bytes
• ASCII is a 7 bit character set (0-127) – fits into a byte, remaining bit could be set to 0 or used as a parity bit – 95 printable characters, 33 non-printing • Some printable encodings – quotable-printable encoding • printable characters as is
• non printable characters represented as =hex1hex2 – base64 encoding (used in Privacy Enhanced Mail) • use character set of 26 = 64 (A-Z, a-z, 0-9, +, /) • = is used as a special suffice for termination condition • 3 bytes are converted into 4 sets of 6 bit characters • the 6 bit value of each set indexes into the character set • note that 3 bytes encoded as 4 bytes • result (due to termination rules) is output that is a multiple of 4 bytes
5 Unix Password System
• User-entered passwords are • The hash algorithm varies. In converted into bit strings. early systems, the bit-string • A salt (set by the system during for the password is treated user account creation and as a key for (a variant of) stored in the account database) DES. The salt is used to is also used as input. indicate which DES variant • A hash / ciphertext of the to use (a salt all of its bits 0 password (using only 64 bits of results in DES being result) and a 12 bit salt are selected). computed, the value encoded in • In modern systems, the hash printable ASCII characters, and is either based on the hash stored in the account database. function MD5, or on the – ellen1 (user name) Blowfish block cipher. – ri (salt) • crypt(3) – ri79KNd7V6.Sk (encrypted password) 6 Example: Salt + Hashing
User id Salt value Password hash
Bob 5b7 h(5b7 || passwordBob)
Alice f3c h(f3c || passwordAlice)
Trudy 33a h(33a || passwordTrudy)
• The hash function encodes the output into a printable string of characters • Salt is mainly used for against dictionary attacks: – Note: the salt value is in the open; without salt, someone could simply hash a dictionary and compare against all hashed entries – Salt starts with $digit$ indicate the cryptographic algorithm used to compute password 7 Features of Unix Passwords
• The user must know the password to authenticate himself/herself
• Transmitting password for remote authentication – That creates problems for remote authentication---the password must be sent over the network connection. This requires extraneous methods to protect the connection. • Dictionary attacks – If the hashed password and salt are obtained (say, by compromising the user database), it is possible to perform dictionary attacks to recover the password.
8 Dictionary Attacks
• A word list is compiled • Dictionary entries (often in several languages), as well as common proper names, are included in such lists. • Often the list is expanded to include some simple variations, such as “b1rd” or “hell0”.
• Online and offline dictionary attacks – Online dictionary attack: try to login with each password in the dictionary.
9 Offline Dictionary Attacks
• Offline dictionary attack: All the entries of the word list are hashed, and the result is stored in a database. – Note that each word must be hashed with each possible salt value. – When the account database is compromised, the attacker can compare with the pre-computed data to break simple passwords in a very short time. – The use of salt can increase the pre-computation/storage requirements of attacks. But powerful time-memory trade-off algorithms are available to handle even large salt spaces, such as 64-bit salts. • Brute-force attack: For relatively short passwords, all possible variations can be pre-computed and storage, using the same time-memory trade-off strategies.
10 Mitigation Strategies
• Force users to choose good passwords – Specify need to include lower and upper-case alphabet characters, digits and non-alphanumeric keys. – Checking them against dictionary attacks • Make users change passwords often • Use salted passwords – note that the salt does not solve the problem of poor password choices, only makes attacks against reasonably good passwords more costly).
11 Eavesdropping and Server Database Reading
• Remote authentication – Need to protect both communication channel and server database • Communication channel – Authentication information is transmitted • Server database – Authentication information is stored
• Can we protect both if we are using – Password-based authentication – Cryptographic algorithm based authentication
12 Passwords: Protecting against Database Disclosure but not Eavesdropping
Alice Bob
stores Alice, fiddlesticks hash of Alice’s password
Server Bob would hash the password provided by Alice and compare it with stored value
13 Secret Key: Protecting against Eavesdropping but not Database Disclosure
Alice Bob Alice stores nonce R Alice’s Secret X = F(R, Secret)
Server Bob can compare X with what it can compute - note that eavesdropping does not disclose (much) information.
14 Public/Private Key: Protecting against Eavesdropping and Database Disclosure Alice Alice Bob
uses knows private nonce R Alice’s key Public KS Key X = sign[R]KS KP
Server Bob can verify [X]KP using Alice’s public key. Note: it is difficult to protect against both situations without using public / private keys, but Lamport’s hash is a fairly good algorithm.
15 Challenge and Response: hash value kept secret
• Some systems enable secure remote authentication via passwords by the following method – The system generates a random challenge R – The user returns a function F(R, H), where H is the hash of his/her password – The user has previously entered the password in the remote system, which computes the hash H from it and stores this hash. – The system is thus able to compute F(R, H). • Note that the hash is playing the role of a shared secret and must be kept secret by the system
16 Negative Features of such Challenge-Response Authentication
• Compromise of the account database of hashed password enable remote authentication without having to guess the password – Since the server only knows the hash, not the password, the mechanism must use the hash directly • Vulnerable to offline dictionary and brute-force attacks on the password by eavesdropping on the transmitted values F(R, H). – Note that R is sent in the clear, so the adversary does not even need to compromise the account database to capture values and mount an offline attack.
17 Challenge-Response: Strong Mutual Authentication with Shared Secret K Bob Alice rA
K(rA)
rB
K(rB)
What is the flaw if Trudy impersonates Alice? Hint: suppose two channels are opened from Trudy (Alice) to Bob 18 Challenge-Response: Strong Mutual Authentication with Hash Function
Bob Alice rA
MD(rA,K)
rB
MD(rB,K)
What are the advantages over secret key cryptographic algorithms?
19 Same Simple Mutual Authentication (flawed)
Bob Alice idA, rA
MD(rA,K), idB, rB
MD(rB,K)
Flaw is that a reflection attack is possible
20 Attack 2 on the Simple Mutual Authentication Protocol
• Reflection Attack: Trudy impersonating Bob • Original session • Second session
1. A -> B: rA 2. Trudy intercepts
3.T -> A: rA
4. A -> T: MD(rA, K), rD
5.T -> A: MD(rA, K), rB
6. A -> T: MD(rB’ K)
Note that we have previously discussed the case where Trudy impersonates Alice termed Attack 1 for this flawed
protocol. 21 Result of Attack 2
• Alice believes that she is in a secure session with Bob, but Bob is not involved and is not aware that there is a session. • Alice is in a session with Trudy
22 Ways to Fix Mutual Authentication Problems
• Initiator should prove its identity first (Alice) • Use different keys to authenticate Alice and Bob • Derive the key for authenticating Bob from Alice’s key • Insist that challenges look different from initiator and responder
23 Same Simple Mutual Authentication (immune to reflection attack)
Bob Alice idA
idB, rB
MD(rB, K), rA
MD(rA, K)
Initiator proves identity first. Show that a reflection attack does not work whether Trudy impersonates Alice or Bob. 24 Session Keys
• Session keys should be used for securing channels, with long-term key only for authentication – Reduces amount of information encrypted under the same key; makes cryptanalysis difficult – Prevents replay attacks • Known-key attack: – Long-term keys derivable from session transcript + session key (BAD!)
25 More on Session Keys
• Leak of a session-key should NOT enable discovery of further session keys – Otherwise as bad as leaking the long-term key • Forward secrecy: – Previous session keys undiscoverable after compromise of a session key – Previous session keys undiscoverable after compromise of a long-term key • This last level of security requires techniques from public key cryptography
26 Reading Assignment
• Sections 11.4, 11.5, 13.1 - 13.7 • Paper 10
27