CIS 433/533 - Computer and Network Security Authentication

CIS 433/533 - Computer and

Network Security

Authentication

Professor Butler

Winter 2011

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

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

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.

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 …

Credentials

•

_{… are evidence used to prove identity}

•

_{Credentials can be}

‣ Something I am

‣ Something I have

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}

Something you have …

•

_{Tokens (transponders, …)}

•

_Smartcards

•

_{Digital Certificates (used by Websites to}

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

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)

GET /protected/index.html HTTP/1.0

HTTP/1.0 401 Unauthorized

WWW-Authenticate: Basic realm=“Private”

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

CLIENT

CLIENT CLIENT

Setting up Basic auth in Apache

•

File in directory to protect (.

!!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

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}

GET /protected/index.html HTTP/1.1 HTTP/1.1 401 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 CLIENT CLIENT

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

•

_{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

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

Password Attacks

•

_{Dictionary attack}

‣ Users not so good at picking high-entropy passwords

‣ Gawker:

•

_{Rainbow Table}

‣ precomputed hash values: big

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.

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?

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

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...)

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?}

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}

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

Ticket (K

₎

“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₎

Ticket

(K

)

The protocol (obtaining a TGT)

•

Time

- time of expiration

•

_{n - nonce (random, one-use value: e.g., timestamp)}

Alice

KDC

[A,TGS,Time

,n]

1

E(k

_,[k

_,TGS,Time

exp

,n]),

E(K

,[A, k

,

],)

2

The protocol (performing authentication)

Alice

Bob

[B,Time_exp,n,E(kA,TGS_,[B,Time

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

E(k

_,[k

_,B,Time

exp

,n]),

E(k

_,[A,k

_,Time

_])

2

TGS

3

E(k

_,[A,k

_,Time

_])

_,

E(k

_{,[A,Timeexp,n])}

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.”

UW

_Oregon

Stanford

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}

Meeting Someone New

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}

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

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}

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}

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

CA1n

CA21

CA31

Certificate Validation

…

…

…

Root

CA1

_CA2

_CA3

CA11 CA12

CA1n

CA21

CA22

Cert11a Cert11b Cert11c

…

…

…

…

Certificate Signature

Certificate Validation

…

…

…

Root

CA1

_CA2

_CA3

CA11 CA12

CA1n

CA21

CA22

Cert11a Cert11b Cert11c

…

…

…

…

Certificate Signature

Certificate Validation

…

…

…

Root

CA1

_CA2

_CA3

CA11 CA12

CA1n

CA21

CA22

Cert11a Cert11b Cert11c

…

…

…

…

Certificate Signature

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

PKI (Circa 2009/2010)

Verisign

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

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}

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}

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}

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

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

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}

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

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

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?}

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