pwdArmor : Protecting Conventional Password Authentications - PowerPoint Presentation

Slide1

pwdArmor: Protecting Conventional Password Authentications

Tim van der Horst and Kent SeamonsInternet Security Research LabBrigham Young University

24

th

Annual Computer Security Applications Conference

December 8-12, 2008

Anaheim, California, USASlide2

The Problem

Password logins often need an encrypted tunnel to prevent exposure of the user’s password

HTML login pages

SSH “keyboard-interactive”

Username:

Password:

Bob

p455w0rd

Username: Bob

Password: p455w0rd

Encrypted Tunnel

(e.g., TLS)

Encrypted tunnels can be circumvented

The tunnel also authenticates the hostSlide3

Circumventing Encrypted TunnelsAssume user is talking to the attacker

Do not create itHope the user doesn’t noticeCertificate trickValid certificate for the attacker

Or assume user ignores browser

warnings

Username: Bob

Password: p455w0rd

Encrypted Tunnel

(e.g., TLS)

99.23% of Phishing occurs over plain HTTP*

* Anti-Phishing Working Group, January 2008Slide4

Goals for pwdArmor

Prevent exposure of the plaintext passwordEven without the encrypted tunnelMitigate damage when authenticating to the wrong host

Limit effectiveness of password phishing

Reuse existing password protocols and verifier databases

Maintain compatibility with legacy systemsSlide5

Target Deployment Scenarios

Sclear Unencrypted channel for communicationsE.g., HTTP

S

tunnel

Encrypted channel for communications

E.g., HTTPS, SSH

Use tunnel for:

Improved identification of the host

Secure the resulting sessionSlide6

Conventional Password Protocols

User-side

Pwd

Protocol Module

Host-side

Pwd

Protocol Module

ID

U

[C]

R

U

[R

H

]

Username:

Password:

Bob

p455w0rd

Username

Password

Verifier Database

Lookups based on the identifier

Optionally generate a challenge

Derive an authentication response from password (and C, if Present)

Optionally generate its own auth response

Verify the auth response

Verify the auth response

May require up to two roundsSlide7

pwdArmor

is Middleware

User-side

Pwd

Protocol Module

Host-side

Pwd

Protocol Module

Username:

Password:

Bob

p455w0rd

Verifier Database

Host-side

pwdArmor

User-side

pwdArmor

Works in concert with an encrypted tunnel

Or without oneSlide8

Encrypt user’s authentication response (RU)pwdArmor

: High Approach

ID

U

[C]

[R

H

]

R

U

ID

H

ID

HSlide9

Something only the real server should know

Something only the other party should know

pwdArmor

: High Level Approach

Encrypt user’s authentication response (R

U

)

Key based on two parts:

K

U,H

= result of a

Diffie-Hellman (DH) key exchangeAn attacker must compromise DH exchange

The user’s password verifierAn attacker must compromise the legitimate hostAdd the host identifiers (IDH) as perceived by the user

Allow the host to detect man-in-the-middle attacks

Scenario

IDH

SclearNetwork identifiers (e.g., domain name, network address)

StunnelHost’s certificate and network identifiers Slide10

pwdArmor Framework

[C]

ID

H

n

U

n

H

g

y

g

x



E( )

ID

U

R

U

ID

H

ID

U

MAC( )

[R

H

]

ID

U

ID

H

Key Derivations

K

U,H

PRF

r

(

g

xy

); r =

n

U

||

n

H

Encryption

Key

PRF

K

U,H

(verifier, “enc”)

MAC Key

PRF

K

U,H

(verifier, “

mac

”)

DH Key Exchange

 contains the info necessary to derive the verifier from the password

DH

DH

DH

DH

Use ID

U

to lookup the correct verifier and may be necessary for [C]

Verifier is used to help compute the Encryption and MAC keys

ID

U

ensures that the host got the correct ID

U

ID

H

used to help detect man-in-the-middle attacks

Encrypted TunnelSlide11

Deployment ConsiderationClient-side support is required to use

pwdArmorSignificant deployment hurdleWeb browsers are nice test-bed for incremental deploymentBrowser extensions, zero-footprint clients (e.g., Java Applets)

The user’s password must be given to the client-side software

Not a problem for many situations

SSH client, wireless supplicants, etc.

Significant problem for web browsersMost logins use a server-supplied HTML login page

Entering passwords via the browser’s chrome is an attractive alternativeProvides a consistent login experience across all domains

Web browsers already have rudimentary support for this to enable HTTP Basic and Digest authentications

Increased willingness by major players to provide client-side support (e.g.,

CardSpace

, Higgins)Slide12

Security AnalysisThreat model2 Scenarios

3 Attacks2 AttackersAnalysis using the modelConventional password protocolspwdArmor

S

clear

S

tunnelSlide13

Threat Model – AttacksPWD

breakObtain the user’s password (or equivalent)LEAK breakObtain material to verify an offline guessing attack

MITM

break

Mount a man-in-the-middle attack without detection

Judge the success of an attack based on which breaks are possibleSlide14

Man-in-the-Middle (MITM) AttacksThree typesRouting

Attacker controls a router on the path to the hostPharmingDNS is poisoned so that lookups for the host point to the attackerPhishingUser connects directly to the attacker

ARP Poisoning

Clicks on a link in a phishing emailSlide15

Threat Model – AttackersEvePassive eavesdropper

Goals: PWD and LEAK breaksMallory

Active attacker

Goals:

PWD

, LEAK

, and MITM breaks

Limited to observing normal interactionsSlide16

Analysis:Conventional Password Protocols

Three types of protocolsClassified by the characteristics of RU

Password verifiers

Type

R

U

is

replayable

RU facilitates an offline guessing attack

Type-0

YESYES

Type-1NOYES

Type-2NO

NO

HTML forms

HTTP Digest, OTP

PAKE protocols

SRP, SPEKE

Verifier = Hash(Password)

Verifier = Password

TypeVerifier can be used to impersonate user

Password-equivalentYESPassword-dependent

NO

Verifier used as the password (e.g., Kerberos)Slide17

Analysis:Conventional Password Protocols

If tunnel is used and correctly establishedNone are vulnerable to Eve or MalloryIf tunnel is not used or incorrectly

established

Type-0

Type-1

Type-2

Eve

PWD, LEAK

LEAK

None

Mallory

PWD, LEAK,

MITM

LEAK, MITM

None

Why not just use Type-2?

Primary reason:

pwdArmor can reuse existing verifiers and maintain their password-dependence

TypeRU

is replayable

RU facilitates an offline guessing attack

Type-0YESYES

Type-1NOYES

Type-2NO

NO

The password protocol is not bound to the encrypted tunnelSlide18

Analysis:pwdArmor

PWD breaksRU is encryptedEncryption key is

based on the password verifier

Thwarts Eve and Mallory

LEAK

breaksDH key exchange thwarts a passive break

If tunnel is not used or incorrectly establishedVulnerable to DH-MITM attackMallory can use EKU,H

(IDU, RU, IDH) to verify offline password guesses

[C]

n

U

n

H

g

y

g

x



E( )

ID

U

R

U

ID

H

ID

U

MAC( )

[R

H

]

ID

U

ID

H

DH

DH

DH

Key Derivations

K

U,H

PRF

r

(

g

xy

); r =

n

U

||

n

H

Encryption

Key

PRF

K

U,H

(verifier, “enc”)

MAC Key

PRF

K

U,H

(verifier, “

mac

”)

K

U,H

Guess



Verifier

K

U,H

Check GuessSlide19

Analysis:pwdArmor

MITM breaksOnly possible when Malloy can conceal her presence from both user and hostDifficulty depends on the scenario

ID

H

Host can detect when user uses

S

clear

instead of

S

tunnel

S

clear

S

tunnel

Phishing

No

No

Pharming

No

No

Routing

Yes

No

DH-MITM destroys the ability to obtain a

MITM

breakSlide20

Conventional

Password ProtocolspwdArmorTunnel

No Tunnel

Bad Tunnel

Type-0/1

Eve

None

Mallory

LEAK,

MITM*

*

Only for routing-MITM

Type-0/1

Eve

None

Mallory

LEAK

Type-0

Type-1

Type-2

Eve

PWD, LEAK

LEAK

None

Mallory

PWD, LEAK,

MITM

LEAK, MITM

None

Analysis SummarySlide21

ConclusionspwdArmor is a more secure alternative than an encrypted tunnel (by itself) to protect conventional password protocols

Key benefit apparent when been phishedUser’s password is never disclosedAn encrypted tunnel is a bonus, not the linchpinReuse existing password protocols and databases of password verifiers

Retains compatibility with legacy systems

Maintains their password-dependent nature, if presentSlide22

Implementation

Clients

Firefox extension

Java Applet

Server

Tomcat filter

libpwdarmor

MD5-based BSD algorithm

MD5-based BSD algorithm

(Apache variant)

HTTP Digest H(A1)

MD5-based OTP

SHA1-based OTP

Verifiers

HTTP Basic

OTP

ProtocolsSlide23

Implementation: 3 ExamplesHTTP Basic

MD5-based BSD verifiersOTP

HTTP Basic

HTTP Digest verifiers

Verifiers were originally stored in a dependent way but used in an equivalent fashion

[C]

n

U

n

H

g

y

g

x



E( )

ID

U

R

U

ID

H

ID

U

MAC( )

[R

H

]

ID

U

ID

H

DH

DH

DH

Basic w/ BSD



alg

=apr1, salt=

CGyXh

…

R

U

password

OTP w/ SHA1



alg

=otp-sha1, seed=

pongo

,

cnt

=100

C

Otp-sha1 99

pongo

R

U

AND FULL FAN GAFF BURT HOLM

Basic w/ Digest



alg

=http-digest, realm=

Hoth

R

U

password

Thwarts the “small n” attackSlide24

OutlineThe problemOur solution

A security analysisOur implementationThe conclusionsSlide25

Mention the compound authentication problemHow EAP solves itWhy we’re not doing it that way

Extensible authentication protocol (EAP)Addresses the compound authentication problemNo protection if host is not correctly verifiedSlide26

Notation

pwd

U

= User’s password

= User’s password verifier

= Verifier(

pwd

U

,

); (e.g.,  = salt)

pwd

U

verSlide27

Visualized Another Way

pwdArmor

Password Protocol

Password ProtocolSlide28

pwdArmor is MiddlewareSlide29

Protocol Ladders from WISEC

I’m

Alice`

DNSSlide30

Threat Model -- AttacksPWD LEAK MITM

PWD LEAK MITMPWD LEAK MITMPWD LEAK MITMSlide31

Our Solution – OutlineThreat Model

Existing password protocolspwdArmorSlide32

Our SolutionMiddleware approach

Username:

Password:

Bob

p455w0rdSlide33

Our SolutionSlide34

Conventional

Password ProtocolspwdArmorTunnel

No Tunnel

Bad Tunnel

Type-0/1

Eve

None

Mallory

LEAK,

MITM*

*

Only for routing-MITM

Type-0/1

Eve

None

Mallory

LEAK

Type-0

Type-1

Type-2

Eve

PWD, LEAK

LEAK

None

Mallory

PWD, LEAK,

MITM

LEAK, MITM

None