29 Oct 2015 CSCD27 Computer and Network Security Authenticating Humans CSCD27 Computer and Network Security 1 Authenticating Computers and Programs Computers and programs need to authenticate one another: e.g. mutual-authentication mechanisms using nonces and symmetric keys SSL/HTTPS server authentication based on CA-signed certificate What about human beings? CSCD27 Computer and Network Security 2 CSCD27F Computer and Network Security 1
29 Oct 2015 Authenticating Humans What evidence can you provide to prove that you are who you say you are, or perhaps at least are someone with authorization to do something? to another human? EXAMPLES? to a machine (computer, program)? EXAMPLES? Is this a hypothetical (e.g. sci-fi) scenario, or is it something we do routinely in our daily lives? Can we solve the problem of authentication-based attacks by eliminating authentication? CSCD27 Computer and Network Security 3 Passwords as Authenticators An example of security based on what you know, vs what you have (e.g. RFID transponder) or what you are (e.g. biometrics) Humans prefer short, memorable key values (commonly 8 characters, 56/64 bits if using ASCII) Can use directly, or as basis for constructing longer key directly e.g. as DES 56-bit key can t use for RSA p,q: o but, could use as random-#-generator seed to generate p,q Commonly used by operating systems and Web applications as a way of checking that the user is who they say they are. Challenges: easy to remember, hard to guess, keeping secret CSCD27 Computer and Network Security 4 CSCD27F Computer and Network Security 2
29 Oct 2015 Passwords in Practice (the grim reality) Security policies can have unintended consequences, e.g.: Should use different password for each account users actually use single password Passwords must be at least N characters, e.g. 8-10 users pad shorter passwords Passwords must not be dictionary words (must be truly random = high entropy) checked or generated by program users write down passwords or store in unencrypted file Passwords must contain a mix of upper/lower-case, digits users add digit 1 to shorter password, reuse same password with upper-case initial character Passwords must be changed regularly users append date to password (whose core remains static) CSCD27 Computer and Network Security 5 Passwords in Practice A large proportion of passwords in the wild are exceptionally weak, e.g. top-10 from RockYou.com password database breach in 2009 (accounting for 2% of 32 million passwords): 1. 123456 2. 12345 3. 123456789 4. password 5. iloveyou 6. princess 7. 1234567 8. rockyou 9. 12345678 10. abc123 CSCD27 Computer and Network Security 6 CSCD27F Computer and Network Security 3
29 Oct 2015 Passwords in Practice (significance) OK, average person is not very savvy when it comes to password selection, so what? Sometimes you can t protect people from themselves, no matter how hard you try Imagine that you are a sys/network admin for a company. You take care to select appropriately secure passwords for system/admin accounts, and for yourself If some staff member doesn t follow your advice, and chooses 123456 as their password, does that affect you (or your employer)? Why/not? 1. 123456 2. 12345 3. 123456789 4. password 5. iloveyou 6. princess 7. 1234567 8. rockyou 9. 12345678 10. abc123 CSCD27 Computer and Network Security 7 Passwords as Authenticators Advantages: portable, standalone user-remembered password can be use anywhere no additional client-side certificates, technology required but many advocate for multi-factor authentication Defending against attacks Network should not send cleartext passwords o can you think of a situation that violates this rule? Malicious users should not have opportunity to conduct offline dictionary attacks o what s the harm, if a password is well chosen? Malicious server (as in phishing) should not learn password by communicating with honest user o want to protect users from accidentally divulging passwords to 3 rd parties CSCD27 Computer and Network Security 8 CSCD27F Computer and Network Security 4
29 Oct 2015 Password System: First Attempt Basic password system: file w/ username, password records (colon delimited) john:car mary:chariot joe:czablozk Simple to implement, but risky If attacker gets a copy of the password file, all user accounts are compromised maybe even worse, if these account names and passwords are used on other systems too, a common behavior CSCD27 Computer and Network Security 9 Password Encryption Idea: rather than storing passwords in plaintext, why not encrypt them! Advantage: if password file stolen, passwords not (immediately) compromised Encrypt at client-side for secure transmission Server could decrypt (e.g. DES, AES) to check Issues: o key exchange with client-side? o key storage what if server-key is compromised?? o ugh, cure worse than the disease? If only we had a way to encrypt without a key have we seen an example of that? CSCD27 Computer and Network Security 10 CSCD27F Computer and Network Security 5
29 Oct 2015 Password Encryption Insight: server doesn t actually require users plaintext passwords, only needs to match what users supplied at time account created Could thus use one-way encryption, using what? Even better than encryption; now no way to decrypt! if password file stolen, passwords not compromised nosy sys admin can t read your password Have we seen a suitable way to encrypt one-way? Use secure hash function, one-way (pre-image protection) and 2 nd -preimage protection e.g.: store SHA-1 hash rather than plaintext password CSCD27 Computer and Network Security 11 Hashed Passwords User pomegranate hash function Password file :exrygbzyf: :kgnosfixa: :ggjoklbsz: CSCD27 Computer and Network Security 12 CSCD27F Computer and Network Security 6
29 Oct 2015 Basic Hashed-Password Setup User chooses password Hash of password stored in password file User logs into system by supplying password System computes hash of supplied password, compares to hash value stored password file Attacks Online dictionary attack o try to log in by repeatedly guessing password (defense?) Offline dictionary attack o steal password file, search for string with hash(string) in password file (tells you what?) CSCD27 Computer and Network Security 13 Dictionary Attacks Attacker Obtains Password File: joe mary john 9Mfsk4EQ... AEd62KRD... J3mhF7Mv... Online: test guesses against live system Offline: attacker steals password file; tests guesses Summer 2012 LinkedIn 6M hashed passwords posted online in.ru maryhas password chariot! Attacker computes possible password hashes (using words from dictionary) h(car) = 9Mfsk4EQ... h(cello) = z5wcujwe... h(chariot) = AEd62KRD... h(daft) = tvj/d6r4 CSCD27 Computer and Network Security 14 CSCD27F Computer and Network Security 7
29 Oct 2015 Middle Earth Dictionary Attacks CSCD27 Computer and Network Security 15 Dictionary Attack some numbers If passwords were actually random strings Assuming a seven-character password o upper- and lowercase letters, digits, 32 punctuation characters o 64,847,759,419,264 possible values; maybe reasonable deterrent But could users remember them? And if not? Typical password dictionary 1,000,000 entries of common passwords o ordinary words, peoples names, place names, etc. Suppose you generate and analyze 10 guesses per second o this may be reasonable for a Web site; offline muchfaster Dictionary attack in at most 100,000 seconds = 28 hours, or 14 hours on average reality check: GPU up to 3B hash calculations per second CSCD27 Computer and Network Security 16 CSCD27F Computer and Network Security 8
29 Oct 2015 Dictionary Attack Mitigation How could dictionary attacks be thwarted? problem: a dictionary attacker can immediately see which users have the same password crack one instance and you get the whole set problem: once an attacker hashes a dictionary into a table of hash values, can use this precomputed table against all systems(with same OS/version), why? Goal: mitigate both problems: block use of precomputed lookup tables randomize same-password hashes CSCD27 Computer and Network Security 17 Unix password file entry: alice:furfuu4.4hy0u:129:129:admin:/home/alice:/bin/csh Password Input Constant (0) Plaintext Salt Key 25x DES Idea: Salt Compare Ciphertext Where does salt come from? chosen randomly when password set, egclock time why constant 0? Just encrypting null plaintext Now users with same password have different entries in the password table, across all systems; attack table must account for all possible hash values (attack cost now much higher) CSCD27 Computer and Network Security 18 CSCD27F Computer and Network Security 9
29 Oct 2015 Idea: Salt Unix password file entry: alice:furfuu4.4hy0u:129:129:admin:/home/alice:/bin/csh Password Input Salt catenate Hash Compare Hash value Where does salt come from? chosen randomly when password set, eg clock time Same idea as prior slide, but with secure hash rather than DES Now users with same password have different entries in the password table, across all systems; attack table must account for all possible hash values (attack cost now much higher) CSCD27 Computer and Network Security 19 Advantages of Salting Without salt, attacker can pre-compute hashes of all dictionary words once for all password entries same hash function on all same-version Linux/UNIX machines one table of hash values can be used for all password files therefore attacker willing to expend considerable effort to build this table With salt, attacker must recomputehashes of all dictionary words for each possible salt value With original Unix 12-bit random salt, same password can hash to 2 12 different values (now use 48 to 128-bit hash value) o users with same password have different hashed password values o minimal incremental effort to implement salting Attacker must try all dictionary words for each salt value in the password file huge change in cost/effort for attack CSCD27 Computer and Network Security 21 CSCD27F Computer and Network Security 10
29 Oct 2015 Shadow Passwords Dictionary attacks still possible with salt? o if have an account on target system, /etc/password file readable, perform dictionary attack for each salt found o why is /etc/password file readable?! Idea: store hashed passwords in /etc/shadowfile, readable only by system administrator (and root programs) alice:x:129:129:admin:/home/alice:/bin/csh Hashed password is not stored in a world-readable file password file entry But, always keep in mind weakest link: system backups? Stored where? CSCD27 Computer and Network Security 22 CSCD27F Computer and Network Security 11