CIS 433/533 - Computer and Network Security Authentication

Transcription

1 CIS 433/533 - Computer and Network Security Authentication Professor Butler Winter 2011 Computer and Information Science

2 What is Authentication? Short answer: establishes identity Answers the question: To whom am I speaking? Long answer: evaluates the authenticity of identity proving credentials Credential is proof of identity Evaluation process that assesses the correctness of the association between credential and claimed identity for some purpose under some policy (what constitutes a good cred.?) 2

3 Why authentication? Well, we live in a world of rights, permissions, and duties? Authentication establishes our identity so that we can obtain the set of rights E.g., we establish our identity with Tiffany s by providing a valid credit card which gives us rights to purchase goods ~ physical authentication system Q: How does this relate to security? 3

4 Why authentication? (cont.) Same in online world, just different constraints Vendor/customer are not physically co-located, so we must find other ways of providing identity e.g., by providing credit card number ~ electronic authentication system Risks (for customer and vendor) are different Q: How so? Computer security is crucially dependent on the proper design, management, and application of authentication systems. 4

5 What is Identity? That which gives you access which is largely determined by context We all have lots of identities Pseudo-identities Really, determined by who is evaluating credential Driver s License, Passport, SSN prove Credit cards prove Signature proves Password proves Voice proves Exercise: Give an example of bad mapping between identity and the purpose for which it was used. 5

6 Credentials are evidence used to prove identity Credentials can be Something I am Something I have Something I know 6

7 Something you know Passport number, mothers maiden name, last 4 digits of your social security, credit card number Passwords and pass-phrases Note: passwords are generally pretty weak University of Michigan: 5% of passwords were goblue Passwords used in more than one place Not just because bad ones selected: If you can remember it, then a computer can guess it Computers can often guess very quickly Easy to mount offline attacks Easy countermeasures for online attacks 7

8 Something you have Tokens (transponders, ) Speedpass, EZ-pass SecureID Smartcards Unpowered processors Small NV storage Tamper resistant Digital Certificates (used by Websites to authenticate themselves to customers) More on this later 8

9 Something you are Biometrics measure some physical characteristic Fingerprint, face recognition, retina scanners, voice, signature, DNA Can be extremely accurate and fast Active biometrics authenticate Passive biometrics recognize Issues with biometrics? Revocation lost fingerprint? fuzzy credential, e.g., your face changes based on mood... Great for physical security, not feasible for on-line systems 9

10 Web Authentication Authentication is a bi-directional process Client Server Mutual authentication Several standard authentication tools Basic (client) Digest (client) Secure Socket Layer (server, mutual) Cookies (indirect, persistent) Q: Are cookies good credentials? 10

11 How Basic Authentication Works CLIENT GET /protected/index.html HTTP/1.0 CLIENT HTTP/ Unauthorized WWW-Authenticate: Basic realm= Private GET /protected/index.html HTTP/1.0 Authorization: Basic JA87JKAs3NbBDs CLIENT 11

12 Setting up Basic auth in Apache File in directory to protect (.htacess)!!authtype Basic!!AuthName Kevin s directories (User ID=butler)"!!AuthUserFile /usr/butler/www-etc/.htpw1!!authgroupfile /dev/null!!require valid-user In /usr/butler/www-etc/.htpw1!! butler:l7fwweqjyzmno generated using htpasswd program Can use different.htaccess files for different directories 12

13 Basic Authentication Problems Passwords easy to intercept Passwords easy to guess Just base-64 encoded Passwords easy to share No server authentication Easy to fool client into sending password to malicious server One intercepted password gives eavesdropper access to many documents 13

14 Digest Authentication CLIENT CLIENT GET /protected/index.html HTTP/1.1 HTTP/ Unauthorized WWW-Authenticate: Digest realm= Private nonce= 98bdc1f9f017.. GET /protected/index.html HTTP/1.1 Authorization: Digest username= lstein realm= Private nonce= 98bdc1f9f017.. response= 5ccc069c4.. CLIENT 14

15 Challenge and Response Challenge ( nonce ): any changing string e.g. MD5(IP address:timestamp:server secret) Response: challenge hashed with user s name & password MD5(MD5(name:realm:password):nonce:MD5(request)) Server-specific implementation options One-time nonces Time-stamped nonces Method authentication digests 15

16 Advantages of Digest over Basic Cleartext password never transmitted across network Cleartext password never stored on server Replay attacks difficult Intercepted response only valid for a single URL Shared disadvantages Vulnerable to man-in-the-middle attacks Document itself can be sniffed 16

17 Password Attacks Use of passwords in, for example, Kerberos is susceptible to offline cracking Process: User enters password for Kerberized client Request (w/o password) forwarded to KDC Response is encrypted in key derived from user s passwd Client generates key from password for decryption Attack: If you know what the message should say, you can guess and test passwords PSU: we did this, recovered 35% of CSE passwds Can also spoof logins to recover passwds 17

18 Password Attacks Dictionary attack Users not so good at picking high-entropy passwords Gawker: password qwerty 498 abc monkey consumer 376 letmein dragon 307 trustno1 Rainbow Table precomputed hash values: big 18

19 A petard... The rule of seven plus or minus two. George Miller observed in 1956 that most humans can remember about 5-9 things more or less at once. Thus is a kind of maximal entropy that one can hold in your head. This limits the complexity of the passwords you can securely use, i.e., not write on a sheet of paper. A perfectly random 8-bit password has less entropy than a 56-bit key. Implication? 19

20 A question? Is there going to come a day where all passwords are useless? Suppose I can remember 16 bytes of entropy (possible?) Won t there come a day when all passwords are useless? Moore s law and its corollaries? 20

21 Answer: no Nope, you just need to make the process of checking passwords more expensive. For example, you can repeat the salted hash many times... Linear cost speedup? 21

22 Kerberos History: from UNIX to Networks (late 80s) Solves: password eavesdropping Online authentication Variant of Needham-Schroeder protocol Easy application integration API First single sign-on system (SSO) Genesis: rsh, rcp authentication via assertion Most widely used (non-web) centralized password system in existence (and lately only...) Now: part of Windows 2K/XP/Vista network authentication 22

23 An aside Authentication Assessing identity of users By using credentials Authorization Determining if users have the right to perform requested action (e.g., write a file, query a database, etc.) Kerberos authenticates users, but does not perform any authorization functions beyond identify user as part of Realm Typically done by application. Q: Do you use any Kerberized programs? How do you know? 23

24 The setup The players Principal - person being authenticated Service (verifier) - entity requiring authentication (e.g, AFS) Key Distribution Center (KDC) Trusted third party for key distribution Each principal and service has a Kerberos password known to KDC, which is munged to make a password key, e.g., k A Ticket granting server Server granting transient authentication The objectives Authenticate Alice (Principal) to Bob (Service) Negotiate a symmetric (secret) session key k AB 24

25 The protocol A two-phase process 1. User authentication/obtain session key (and ticket granting ticket) key from Key Distribution Center 2. Authenticate Service/obtain session key for communication with service Setup Every user and service get certified and assigns password 25

26 A Kerberos Ticket A Kerberos ticket is a token where Alice is the only one that can open it Contains a session key for Alice/Bob (K AB ) Contains inside it a token that can only be opened by Bob Bob s Ticket contains Alice s identity The session key (K AB ) Ticket (K AB ) Ticket (K AB ) Locked by K B Locked by K A Q: What if issuing service is not trusted? 26

27 The protocol (obtaining a TGT) Time exp - time of expiration n - nonce (random, one-use value: e.g., timestamp) 1 [A,TGS,Time exp,n] Alice 2 KDC E(k A,[k A,TGS,TGS,Time exp,n]),e(k TGS,[A, k A,TGS, Time exp ],) TGT 27

28 The protocol (performing authentication) [B,Time exp,n,e(k A,TGS,[B,Time exp,n])], E(K TGS,[A,k A,TGS,Time exp ])] Alice 1 2 TGS 3 E(k A,TGS,[k A,B,B,Time exp,n]), E(k B,[A,k A,B,Time exp ]) E(k B,[A,k A,B,Time exp ]), E(k A,B,[A,Time exp,n]) Bob Authenticator 28

29 Cross-Realm Kerberos Extend philosophy to more servers Obtain ticket from TGS for foreign Realm Supply to TGS of foreign Realm Rinse and repeat as necessary UW Oregon Stanford OSU UCB There is no problem so hard in computer science that it cannot be solved by another layer of indirection. David Wheeler, Cambridge University (circa 1950) 29

30 Kerberos Reality V4 was supposed to be replaced by V5 But wasn t because interface was ugly, complicated, and encoding was infuriating Assumes trusted path between user and Kerberos Widely used in UNIX domains Robust and stable implementation Problem: trust ain t transitive, so not so good for large collections of autonomous enterprises 30

31 Meeting Someone New Anywhere in the Internet 31

32 What is a certificate? A certificate makes an association between a user identity/job/ attribute and a private key contains public key information {e,n} has a validity period is signed by some certificate authority (CA)... identity may have been vetted by a registration authority (RA) Issued by CA for some purpose Verisign is in the business of issuing certificates People trust Verisign to vet identity 32

33 What is a certificate? A certificate makes an association between a user identity/job/ attribute and a private key contains public key information {e,n} has a validity period is signed by some certificate authority (CA)... identity may have been vetted by a registration authority (RA) Issued by CA for some purpose Verisign is in the business of issuing certificates People trust Verisign to vet identity 32

34 Why do I trust the certificate? A collections of root CA certificates baked into your browser vetted by the browser manufacturer supposedly closely guarded (yeah, right) Root certificates used to validate certificate Vouches for certificate s authenticity CA (signs) Certificate Signature 33

35 Public Key Infrastructure System to securely distribute public keys (certificates) Q: Why is that hard? Terminology: Alice signs a certificate for Bob s name and key Alice is issuer, and Bob is subject Alice wants to find a path to Bob s key Alice is verifier, and Bob is target Anything that has a public key is a principal Anything trusted to sign certificates is a trust anchor Its certificate is a root certificate 34

36 What is a PKI? Rooted tree of CAs Cascading issuance Root Any CA can issue cert CAs issue certs for children CA1 CA2 CA3 CA11 CA12 CA1n CA21 CA31 Cert11a Cert11b Cert11c 35

37 Certificate Validation Root CA1 CA2 CA3 Certificate Signature CA11 CA12 CA1n CA21 CA22 Cert11a Cert11b Cert11c 36

40 PKI and Revocation Certificate may be revoked before expiration Lost private key Compromised Owner no longer authorized Revocation is hard The anti-matter problem Verifiers need to check revocation state Loses the advantage of off-line verification Revocation state must be authenticated 37

41 PKI (Circa 2009/2010) Verisign Web.com Google.com Amazon.com... x.com 38

42 10 Risks of PKI This is an overview of one of many perspectives of PKI technologies PKI was, like many security technologies, claimed to be a panacea It was intended to solve a very hard problem: build trust on a global level Running a CA -- license to print money Basic premise: Assertion #1 - e-commerce does not need PKI Assertion #2 - PKI needs e-commerce Really talking about a full PKI (everyone has certs.) 39

43 Risk 1 - Who do we trust, and for what? Argument: CA is not inherently trustworthy Why do/should you trust a CA? In reality, they defer all legal liability for running a bad CA Risk in the hands of the certificate holder Counter-Argument: Incentives Any CA caught misbehaving is going to be out of business tomorrow This scenario is much worse than getting sued Risk held by everybody, which is what you want Everyone has reason to be diligent 40

44 Risk 2 - Who is using my key? Argument: key is basically insecure Your key is vulnerable, deal with it In some places, you are being held responsible after a compromise Counter-Argument: this is the price of technology You have to accept some responsibility in order to get benefit Will encourage people to use only safe technology Q: what would happen if same law applied to VISA? 41

45 Aside: TEMPEST Transient Electromagnetic Pulse Surveillance Technology Monitor EMF emanations to reconstruct signal For example, a video monitor normally exist at around MHz, and can be picked up as far as one kilometer away.... or by a guy in a van across the street, e.g., steal private key. Generally, this is the domain of spy/national security issues Much classified work on signal eavesdropping and prevention 42

46 Risk 3 - How secure is the verif(ier)? Argument: the computer that verifies your credential is fundamentally vulnerable Everything is based on the legitimacy of the verifier root public key (integrity of certificate files) Browsers transparently use certificates Counter-Argument: this is the price of technology You have to accept some risk in order to get benefit Will encourage people to use only safe technology Q: What s in your browser? 43

47 Risk 4 - Which John Robinson is he? Argument: identity in PKI is really too loosely defined No standards for getting credential No publicly known unique identifiers for people So, how do you tell people apart Think about Microsoft certificate Counter-Argument: due diligence Only use certificates in well known circumstances When in doubt, use other channels to help Q: Is this true of other valued items (checks?) 44

48 Risk 5 - Is the CA an authority? Argument: there are things in certificates that claim authenticity and authorization of which they have no dominion rights (such as the right to perform SSL) - this confuses authorization authority with authentication authority DNS, attributes -- the CA is not the arbiter of these things Counter-Argument: this is OK, because it is part of the implicit charge we give our CA -- we implicitly accept the CA as authority in several domains 45

49 Risks 6 and 7 6 : Is the user part of the design? Argument: too many things hidden in use, user has no ability to affect or see what is going on Ex.: Hosted website has cert. of host(er), not page Counter-Argument: too sophisticated for user to understand 7 : Was it one CA or CA+RA? Argument: separation of registration from issuance allows forgery e.g., RA handles vetting, CA makes certificates, so, you better have good binding between these entities or bad things can happen Counter-Argument: this is an artifact of organization, only a problem when CA is bad (you are doomed anyway) 46

50 Risks 8 and 9 8 : How was the user authenticated? Argument: CAs do not have good information to work with, so real identification is poor (as VISA) Counter-Argument: It has worked well in the physical work, why not here? 9 : How secure are the certificate practices? Argument: people don t use them correctly, and don t know the implications of what they do use Point in fact: revocation and expiration are largely ignored in real system deployments Counter-Argument: most are pretty good now, probably won t burn us anytime soon 47

51 Risk 9 - How secure cert. practices? Argument: certificates have to be used properly to be secure Everything is based on the legitimacy of the verifier root public key, protection of its key Lifetime & revocation have to be done Counter-Argument: this is the price of technology You have to accept some risk in order to get benefit Will encourage people to use only safe technology Q: What s in your browser? 48

52 Risk 10 - Why are we using PKI? Argument: We are trying to solve a painful problem: authenticating users. However, certificates don t really solve the problem, just give you another tool to implement it Hence, it is not a panacea Not delivered on its promises Counter-argument? 49