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