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

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 – ● Apache 2 with SSL/TLS: Step-by-Step, Part 2 by Artur Maj – ● Apache 2 with SSL/TLS: Step-by-Step, Part 3 by Artur Maj – ● All In One CISSP Certification Exam Guide by Shon Harris ● Microsoft Windows 2000 Server Documentation – ault.asp?url=/windows2000/en/server/iis/htm/core/iiabasc.htm ault.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