cis 433/533 - computer and network security...

Computer and Information Science

CIS 433/533 - Computer and Network Security

Authentication

Professor ButlerWinter 2011

CIS 433/533: Computer and Network Security

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


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


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


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


Credentials

• … are evidence used to prove identity

• Credentials can be

‣ Something I am

‣ Something I have

‣ Something I know

6

http://www.education-1.net/Administrative%20Credential%2003-30-02.jpg

http://www.education-1.net/Administrative%20Credential%2003-30-02.jpg


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


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


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


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


GET /protected/index.html HTTP/1.0

HTTP/1.0 401 UnauthorizedWWW-Authenticate: Basic realm=“Private”

GET /protected/index.html HTTP/1.0Authorization: Basic JA87JKAs3NbBDs

CLIENT

CLIENT

CLIENT

How Basic Authentication Works …

11


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


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


GET /protected/index.html HTTP/1.1

HTTP/1.1 401 UnauthorizedWWW-Authenticate: Digest

realm=“Private” nonce=“98bdc1f9f017..”

GET /protected/index.html HTTP/1.1Authorization: Digest

username=“lstein” realm=“Private” nonce=“98bdc1f9f017..” response=“5ccc069c4..”

CLIENT

CLIENT

CLIENT

14

Digest Authentication


• 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

Challenge and Response


• 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

Advantages of Digest over Basic


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 passwds17


Password Attacks

• Dictionary attack

‣ Users not so good at picking high-entropy passwords

‣ Gawker:

• Rainbow Table

‣ precomputed hash values: big

18

2516 123456

2188 password

1205 12345678

696 qwerty

498 abc123

459 12345

441 monkey

413 111111

385 consumer

376 letmein

351 1234

318 dragon

307 trustno1


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


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


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


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


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


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., kA

‣ Ticket granting server

• Server granting transient authentication

• The objectives

‣ Authenticate Alice (Principal) to Bob (Service)

‣ Negotiate a symmetric (secret) session key kAB

24


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


Ticket (KAB)

“Locked” by KA

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 (KAB)

‣ Contains inside it a token that can only be opened by Bob

• Bob’s Ticket contains

‣ Alice’s identity

‣ The session key (KAB)

• Q: What if issuing service is not trusted?

(KAB)Ticket

“Locked” by KB

26


The protocol (obtaining a TGT)

• Timeexp - time of expiration

• n - nonce (random, one-use value: e.g., timestamp)

Alice KDC

[A,TGS,Timeexp,n]1

E(kA,[kA,TGS,TGS,Timeexp,n]),E(KTGS,[A, kA,TGS, Timeexp],)

2

TGT27


The protocol (performing authentication)

Alice

Bob

[B,Timeexp,n,E(kA,TGS,[B,Timeexp,n])], E(KTGS,[A,kA,TGS,Timeexp])]

1

E(kA,TGS,[kA,B,B,Timeexp,n]), E(kB,[A,kA,B,Timeexp])

2TGS

3

E(kB,[A,kA,B,Timeexp]), E(kA,B,[A,Timeexp,n])

28

Authenticator


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

• “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)

UW OregonStanford

OSU UCB

29


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


Meeting Someone New

• Anywhere in the Internet

31


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


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)

CertificateSignature

33


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


What is a PKI?• Rooted tree of CAs

• Cascading issuance

‣ Any CA can issue cert

‣ CAs issue certs for children

… … …

Root

CA1 CA2 CA3

CA11 CA12 CA21 CA31CA1n

Cert11a Cert11b Cert11c … … … …

35


Certificate Validation

… … …

Root

CA1 CA2 CA3

CA11 CA12 CA21 CA22CA1n

Cert11a Cert11b Cert11c … … … …

Certificate

Signature

36


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


PKI (Circa 2009/2010)

38

Verisign

Web.com Amazon.comGoogle.com x.com...


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


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


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


Aside: TEMPEST• Transient Electromagnetic Pulse Surveillance Technology

‣ Monitor EMF emanations to reconstruct signal

‣ For example, a video monitor normally exist at around 55-245 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


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


• Q: What’s in your browser?

43


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


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


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


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


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


• Q: What’s in your browser?48


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

cis 433/533 - computer and network security...

Documents