Bringing Two-factor Authentication to Web Applications

by Michael Starks

2005 March Rochester OWASP

Three Categories of Authentication

● Something you know

● Something you have

● Something you are

Something You Know

● Password or passphrase● Mother's maiden name● Date of birth● Previous address● Pin

Something You Have

● RSA SecurID● Smart card● Smart token● Scratch-off card● Certificate

Something You Are

● Biometrics– Retina or Iris scan– Hand geometry– Finger print– Voice print– Face recognition

● The future– DNA– Behavior recognition

How Many Factors Are Required?

● Any item from the three categories can be considered a token

● Simply put, to authenticate with a token from one category is single-factor authentication and with a token from two categories, two-factor authentication.

● Authentication is predominantly single-factor● The password is the most common form of

authentication

The Problems With Single-factor Authentication

● Most web-based applications authenticate with a password only

● Passwords easily stolen, guessed, recorded and brute forced

● Humans are not well-suited to remembering good and managing passwords

● Passwords are often stored in plain-text or using reversable encryption

Benefits of Two-factor Authentication

● Mitigates the risk of many attacks. – Sniffing, keystroke logging– Social engineering– Replay– Session spoofing– May reduce overall risk of vulnerable web

application● If a single identity token is compromised, the

application should not authenticate the thief.● Non-repudiation

Risks NOT Necessarily Mitigated by Using Two-factor Authentication

● Web applications which are vulnerable are still

vulnerable● Backdoors, trojans, etc● Are your applications still accessible with single-

factor or no authentication?● Web server vulnerabilities● Other vulnerable services running on the same

server or other trusted servers ● DNS hijacking● Many, many more...

Options for Web Applications

● Two-factor authentication of any sort can generally

be added directly to, or as a layer onto, web

applications

● With enough money● With enough time● With enough patience● With enough user-acceptance

● It all goes back to cost

Cost/Benefit Analysis of Common Solutions

● Cost is determined by several factors– Dollars and cents– Order of effectiveness

● How well does it work?

– Order of Acceptance● Biometric acceptance in particular, can be a challenge

– Enrollment● Credentials have to be granted to verified users

– Cost is often determined by the value of the

information you are trying to protect– For many situations, the winner is....

SSL!

● SSL involves the use of asymmetric, as well as

symmetric encryption● SSL is above TCP but below the HTTP layer● SSL can provide not only session layer encryption but

also require the user to present a valid certificate.● A valid certificate can serve as a token from the 'what

you have' category● Combined with a password, as traditionally used in web

applications, authentication then becomes two-factor

Abridged Description of How SSL works

● Client requests secure session from server, while

sending info about ciphers and SSL version supported.● Server responds with SSL version and ciphers

supported● Server presents certificate with includes the public key,

along with some other info● Server optionally requests client certificate● Client presents client certificate, encrypts various info

to the servers public key and optionally signs the

transaction.

Abridged Description of How SSL works (continued)

– If the client certificate is protected by a pass

phrase, the authentication can already be

considered two-factor. If not, it is now single-

factor. ● Symmetric session key is negotiated by the

client, encrypted to the server's public key and sent to the server.

● The actual symmetrically encrypted SSL session begins

Three Ways to Implement Certificates

● Self-signed● Trusted certificate authority signed● Local certificate authority signed

● Each has associated costs and benefits● Intranet environments different than public

web servers.● Effective user enrollment can be time and

logistically expensive, but secure.

X.509v3

Requiring Client Certificates With Apache

1. Decide on self-signed, trusted or local CA

2. If using self-signed or local CA, create server

certificate on an off-line system. If your root CA

certificate is ever compromised, nothing issued by the

root can be trusted. Instead, create another issuing CA

3. If using self-signed or local CA, the certificate will

probably have to be manually distributed and installed

4. If using trusted CA, obtain signed certificate from a

trusted authority

Requiring Client Certificates With Apache (continued...)

1. Install the certificate into Apache

2. Add the following directive to httpd.conf:● SSLVerifyClient require● SSLVerifyDepth 1 (increase n based on the

number of intermediate CAs)

3. At this point you are now requiring client

authentication.

4. Enroll clients in person at your CA for maximum

security.

5. Use further directives for granular security

Requiring Client Certificates With IIS

1. Decide on self-signed, trusted or local CA

2. If using self-signed or local CA, create server

certificate on an off-line system. Microsoft

Certificate Services can be used, as well as

OpenSSL. Remember, if your root CA certificate is

ever compromised, nothing issued by the root can

be trusted. Instead, create another issuing CA

3. In a domain environment, an Enterprise Certificate

Services server can automatically distribute

certificates via Group Policy

Requiring Client Certificates With IIS

1. Install a Certificate Trust List, otherwise IIS will trust all

CAs, potentially even that of an attacker.

2. In IIS, under the properties of the web site, click on the

Directory Security tab, check the 'Require Secure

Channel' box and the 'Request Client Certificates' radio

button

3. At this point you are now requiring client

authentication.

4. Enroll clients in person at your CA, or through Group

Policy for maximum security.

Effects of Using Non-trusted Certificates

Effects of Using Non-trusted Certificates (continued...)

Installing a Non-trusted Certificate in Windows

Installing a Non-trusted Certificate in Windows

Effect of Installing a Non-trusted Certificate in Windows

Recommendations, Summary and Key Points

● Requiring client certificates allows for two-factor

authentication to web applications, but does not

alone make it two-factor● If requiring a client certificate, the certificate

exchange happens before the web application is

accessible, thereby mitigating the risks of many

known and unknown attacks.● Consider cost as it relates to more than dollars and

cents● Consider protecting only sensitive areas

Recommendations, Summary and Key Points (continued...)

● Risks cannot be 100% mitigated. Certificates can

be stolen, users can be social engineered, private

key passphrases can be saved. Think defense-in-

depth.● Consider using open-source based software such

as Apache and OpenSSL, whenever possible● When using certificates for authentication, it is

usually mutual. The user authenticates the server

and the server authenticates the user. Who do you

trust?

Recommendations, Summary and Key Points (continued...)

● Enforce a minimum of 128 bit key lengths with SSL

v3.0/TLS 1.0, if possible.● Consider that NIDS will have a blind eye to SSL

traffic● When distributing client certificates, try to use a

secure out-of-band channel.● Finally, don't have a false sense of security just

because two-factor authentication has been

implemented. Security is more about processes,

policies and people, than technology.

Bibliography

● Apache 2 with SSL/TLS: Step-by-Step, Part 1 by Artur Maj– http://www.securityfocus.com/infocus/1818

● Apache 2 with SSL/TLS: Step-by-Step, Part 2 by Artur Maj– http://www.securityfocus.com/infocus/1820

● Apache 2 with SSL/TLS: Step-by-Step, Part 3 by Artur Maj– http://www.securityfocus.com/infocus/1823

● All In One CISSP Certification Exam Guide by Shon Harris● Microsoft Windows 2000 Server Documentation

– http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiabasc.htm

● Securing Internet Information Services– Part of the Track 5 'Securing Windows' course by the

SANS institute and Jason Fossen