httpdigest corthay

7/31/2019 HttpDigest Corthay

1/16

HTTP Security:Digest AccessAuthentication

Internet Security for

embedded devices

By Emanuel Corthay - EPFL


2/16

ABB

SwitzerlandLtd,

CorporateResearch

-2

20

02ABBallrightsreserved

Network OSI Layers

We focus on the application layer : HTTP HyperText Transfer Protocol


3/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-3

20


SSL and IPsec vs DAA

SSL uses certificates:

Provides server authentication,confidentiality and integrity

Client authentication optional

No configuration transparent

For large servers with manyclients, strong cryptography

Digest Access Authentication:

Password based, challenge-response client authentication

Optional Integrity protection

and server authentication

Use light MD5-hash one-way

function

Standard integrated in web

servers and browsersIPsec:

On the IP level, ideal for VPN

Protect everything using

TCP/IP

Provides authentication,

confidentiality and integrity

Requires network based

configuration


4/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-4

20


HTTP Hyper Text Transfer Protocol

Widely used to exchange text

data accross differentplateforms

Used for the WWW on port 80

to exchange HTML files

Standarized in the RFCs

The current 1.1 version offers

two authentication schemes;

basic and digest

HTTP messages are

composed of header-fields andentity (the payload)

Protocol://destination-host/ressource


5/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-5

20


Basic Access Authentication

Browser Webserver

GET /basic/ HTTP/1.1

Response 401; unauthorized

WWW-authenticate:Basic realm="Basic Test Zone"

HTTP GET Request with clear username and password:

Authorization: Basic dGVzdDp0ZXN0

Response 200; OK

2

3

4

5

1

Password encoded in

Base64; no encryption Sent in clear for every

subsequent requests

Sniffing compromises the

password


6/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-6

20


Generates :

cnonce counternc

URI and method

Browser Web Server

Response HTTP 401 unauthorized

5

1

WWW-authenticate: Digest realm="DigestZone", nonce="3gw6ask",algorithm=MD5, domain="/protected/", qop="auth"

HTTP GET /protected/test.html Request

Authorization:Digest username="Controler", realm="DigestZone",nonce="3gw6ask", uri="/protected/test.html", algorithm=MD5,

response="65biad5s70de", qop=auth, nc=0001, cnonce="82c875dc"

Response HTTP 200 OK

Authentication-Info: rspauth="d9260eef8e7",cnonce="82c875dc", nc=0001, qop=auth

HTTP GET /protected/test2.html Request

Authorization: Digest username="Controler", realm="DigestZone",

nonce="3gw6ask", uri="/protected/test2.html", algorithm=MD5,response="4c5c93bc8747i", qop=auth, nc=0002, cnonce="72g4dsfs"

Response HTTP 200 OK

Authentication-Info: rspauth="g45sx4j65s1",cnonce="3gw6ask", nc=0002, qop=auth

2

nonce generated

HTTP GET /protected/test.html Request

Communicationchannel

MD5-hash

Prompt user for

username and

password

realm, nonce

nonce, cnonce,

URI and method

response

3

4

Match ?

username, realm

No

Yes

401

unauthorized;

Back to

200 OK

Send document

Password Database lookup;

MD5(username:realm:password)

document

Show document,

update nc by 1

Prompt for username

and password again

Back to

code 200

code 401

2

6

3

response

response

MD5-hash

Digest Access Authentication

response = MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI)]


7/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-7

20


Mutual authentication

The server is authenticated

Done via an acknowledgement ; the rspauth header-field

MD5-digest calculated like the browser response

Web ServerBrowser

Requestdocument

Challenge:nonce

Authorization:responseChallenge:cnonce

Acknowledgement:rspauth

rspauth = MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5( :URI)]


8/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-8

20


response =MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI:MD5{entity-body})]

GET /test.html?test&command=1 HTTP/1.1Host: 10.41.74.144

Connection: Keep-AliveAuthorization: Digest username="test", realm="digest",

qop="auth-int", algorithm="MD5", uri="/test.html?test&command=1",

nonce="tC/4qtSqAwA=fbc6ee7ad984a2ccd3f9011c646d1", nc=00004,

cnonce="448e2f9bdd915b6bf", response="d93bf8645d2968867e3a270ff"

Integrity protection

DAA provides a way to protect the transmission integrity

Quality Of Protection qop=auth-int (optional)

A digest of the entity (payload) is included in the response

Protect query sent via POST, queries with GET are already protected

rspauth =MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(:URI:MD5{entity-body})]

Bidirectional with mutual authentication, protect the documents

Like mutual authentication, not yet implemented in all the browsers

and web servers


9/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-9

20


Replay attack

A request from an authenticated

user is intercepted and replayed

A specific request always

includes:

the requested uri

the nonce from the server

A request counter nc

Those fields are protected in theresponse hash, with the password

An attacker must defeat:

The uri check

The nc-counter check

The nonce check

The nonce validity can be limited

to a single use, or to a time period

Implementation dependant

A serious implementation reduces the risks of a replay attack to zero

Authorization: Digest username="Controler", realm="DigestZone",nonce="3gw6ask", uri="/protected/test.html", algorithm=MD5,response="65biad5s70de", qop=auth, nc=0001, cnonce="82c875dc"

response = MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI)]


10/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-10

20


A password in a dictionnary is found within seconds A password with a mix of 8 numbers, upper/lower case characters is

cracked in approximatively 702 years

With only 5 characters (lower case) 20 minutes

Not as safe as SSL / IPsec

Example: My 2sons Jean and Paul are great!M2sJaPag!

Dictionary and brute force attack

Even if the password is protected, it is still possible to try and find it

Try with names and common words

Variation of the username

An attacker can try all the possible passwords = long!

The password choice is critical!

Authorization: Digest username=test", realm=test", nonce="3gw6ask",

uri="/test.htm", algorithm=MD5, response="65biad5s70de", qop=auth,nc=0001, cnonce="82c875dc"

response = MD5[MD5(test:test:?????):3gw6ask:0001:82c875dc:auth:MD5(GET:/test.htm)]


11/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-11

20


Man-in-the-middle attack

The attacker is between the client and the server

The attacker can temper all or part of the communication without theuser noticing it

Web Server

ResponseH

TTP401unauthoriz

ed

WWW-authe

nticate:Dig

est

HTTPGET

/protected/t

est.htmlRe

quest

ResponseHTTP401unauthorized

WWW-authenticate:BasicHTTPGETRequest,clearusernameand

password

Authorization:BasicdGVzdDp0ZXN0

Username and password

HTTPGET

/protected

/test.html

Request

Authorizati

on:Digest

response

="65biad5

s70de"

1

2

3

4

Browser

HTTPGET/protected/test.htmlRequest

The browser can send

basic authenticationinstead of digest

The request can be

modified

The exchanged data can

be modified

Browsers should accept only digest and use visual clues

Not possible with mutual authentication and integrity protection


12/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-12

20


Exploits and DoS

Exploit vulnerabilities in the

program code Usually done using a buffer-

overflow

Everything the program hasaccess to is compromised

Most of the time, crash theserver / client and lead to aDoS

Solution includes frequentupdate and version

dissimulation

Denial Of Service attacks the

availability of the service

Flood the server with requests

Physical DoS Network

outage


13/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-13

20


Server and client implementation

Apache 2.0.42

Support mutual authentication

Nonce check time limited

Strong uri check

RomPager 4.05

One time nonce

Partial uri check

Not working for long uri

GoAhead 2.1.2

Source available

Nonce always valid - dangerous

No uri check - dangerous

Parse errors

Mozilla 1.0.1 / Netscape 7.0

Source available

Keeps prompting the user

Slow

Internet Explorer 6.0.26

Different prompt for basic/DAA

Sends wrong uri dangerous

Opera 6.05

Support mutual authentication

Picky on security

Not working with GoAhead


14/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-14

20


Server and client implementation

No integrity protection available

Great differences in implementation quality

The perfect server / browser doesnt exist yet

Pressure must be applied on the developpers

Clients

Servers

Mozilla 1.0.1

Netscape 7.0

SlowKeeps prompting

the user

Internet explorer

6.0.26

Sends wrong uri

Different prompt forBasic/DAA

Opera 6.05

Requires a right domain

field

Mutualauthentication

Apache 2.0.42 Mutual authentication

Digest auth tested Digest auth tested

Not working for

GET + parameters

Digest auth tested

Requires valid domain

RomPager 4.05Good security, except for GET

with parameters

Digest auth tested

Not working for long

GET + parameters

Digest auth tested Digest auth tested

Not working for long

GET + parameters

GoAhead 2.1.2Weak security

Parsing errors

Digest auth tested

Not working for GET +

parameters

Digest auth tested Not working


15/16

ABB

SwitzerlandLtd,

CorporateRes

earch

-15

20


DAA is

Available on client and servers

Light, but yet secure

Provides integrity protection and mutual authentication

Do not provide confidentiality

Should be used wherever possible, even when used in

conjunction with SSL and IPsec

Systems using basic should be migrated to DAA

Conclusion


16/16

ABB

httpdigest corthay

Documents