The three factors are:
- something you know (password)
- something you are (biometrics)
- something you have
“Something you have” is often out of the question for a web site. “Something you have” means you are managing (purchasing, assigning, distributing, inventorying, collecting, and destroying) devices. Similarly, many biometrics devices are out of the question. Fingerprint scanners and webcams are more entrenched than they were, but their resolution is outside your control.
How about typing pattern recognition? There are many products that can be used to implement this “something you are” as your second factor.
Don’t dismiss “something you have” too quickly. Consider DeepNet Security or PhoneFactor or Authentify; the something you have could me a cell phone. PayPal offers a PayPal Security Key for two factor authentication, in two mechanisms: security code generating device and text message to mobile phone.
“Two factor authentication” may not be your most important concern. Many people look at the problem of web application insecurity as a client authentication problem: “Can I trust that this person is who they say they are?” They increase their confidence with two-factor authentication. Actually, security breeches are often better prevented with two way authentication (mutual authentication). This is typically done business to business (“Can I trust you?” “Yes, but can I trust you?”). There is no reason a business shouldn’t recognize that it has an obligation to its customers. “Can I trust that the customer is actually connecting to my web application, not some man in the middle or impostor?” Extended verification of certificates (qualifying for the green bar in the URL box) is a partial measure. However, this relies upon the customer to manually enforce authentication. Extended validation relies upon the weakest link.
Two way authentication (mutual authentication) can be implemented using SSL See Entrust. See Sun Mutual Authentication for Web Services: A Live Example. At a minimum, be prepared to explain why you have chosen to not do mutual authentication.
Again, see DeepNet or products of its ilk. Just as an example, not an endorsement. But focus on the problem of two way authentication; it could easily be the problem you need to solve.
- Physical One Time Password (OTP) Generators (“Security Tokens”)
- Allow for anytime-anywhere login.
- Are vulnerable to Man-in-the-Middle attacks.
- A sync issue might occur between the token and the Radius server.
- Soft One Time Password (OTP) Generators
- Need to be locally installed, or run from a USB requiring specific user rights.
- Are vulnerable to Man-in-the-Middle attacks.
- A sync issue might occur between the token and the Radius server.
- Mobile Phone SMS One Time Password (OTP) Generators
- Are vulnerable to Man-in-the-Middle attacks.
- Cellphone traffic encryption is not as secure as it was considered. (Although cracking encryption relies upon long conversation, with pauses.)
- SMS delivery may be delayed
- Phoneline One Time Password (OTP) Generators
- Voice synthesis “reads” password to be typed.
- Common Access Cards/smartcards
- X.509 is formal standard.
- Strong authentication during the RA process, and a PIN to remember.
- Protects against Man-in-the-Middle attacks.
- Requires hardware reader.
- Expensive to deploy, expensive to revoke.
- User certificates
- X.509 is a formal standard.
- Can be hard to deploy and revoke.
- Hybrid approaches
- Options range from solutions which create a tamper proof tunnel between user and target server, to SSO portals requiring different combinations of login authentication, to solutions which combine any type of existing authentication with unique user device authentication resulting in time limited secure access tunnels with SSO capabilities enabled.
- May require a hardware or software client component, therefore costs, deployment and revocation difficulties.
- May be SaaS-based and remove troubleshooting and support from local control.
Aggressive Virus Defense 