Want to be more secure? Build two-factor authentication into your webapp

I think the better advice is to completely decouple your authentication from your web app, and then add two-factor authentication to that.<p>We use Kerberos/LDAP at work so are able to use CoSign to provide web SSO. I did a quick write-up about a service that I wrote which allows me to use Google Authenticator as an additional factor with CoSign: <a href="http://it.isevil.org/blog/2011/11/13/authentication-service-using-google-authenticator/" rel="nofollow">http://it.isevil.org/blog/2011/11/13/authentication-service-...</a><p>Since it's just a Sinatra app, the web service could be used by other things. We also use it with FreeRADIUS so our users can use their second factor on the web and in their VPN client.

Two-factor authentication is by definition more annoying than regular authentication. The solution to security is not to add annoyance for users, who will simply hate your product, or disable two-factor.<p>The solution to security is to come up with better and innovative security solutions.<p>Imagine that you had a "log in with iPhone" button, like the common "log in with Facebook" buttons. It would send down a push notification to your iPhone that shows a dialog "Log in to hn.com? Yes | No." Pressing Yes uses fingerprint-sensing capability under the touchscreen to send anonymized[^1] biometric information to provider to authorize the login with.<p>You'd also get a smartphone app to generate temporary login keys for when you need to give a friend access to your account, and get a 32-byte "master" key that can be used to unlock the account without biometric access.<p>[^1]: simply a HMAC / hash value using both the biometric data + the domain being authorized would deal with privacy concerns.

Chances are the only ones who will try this are your users already using two-factor auth somewhere else, and it's most likely they got started with Google. Might as well use an app that's already on their phones, Google Authenticator (<a href="http://news.ycombinator.com/item?id=4348475" rel="nofollow">http://news.ycombinator.com/item?id=4348475</a>)

of course the issue with 2 factors is that:<p>- you can still social engineer your way out (!) - "oh i lost my phone and the recovery keys" "heres my name address cc number, etc please help!" (ie nothing has been solved)<p>- its quite annoying to use<p>- it doesnt solve everything, only weak passwords/brute force<p>- it locks you out if you lose your phone/token until you get back home to get your recovery keys<p>- compromising the phone (2nd factor for the general public) allow compromising both passwords and the authenticator<p>and the issue of passwords managers:<p>- they're stored everywhere because you need them (incl. your phone)<p>- you have a single password to decrypt them all<p>- compromising the phone, once again, give you all passwords, and the authenticator

Before you even think about this can you make sure you've got the basics down. No one in this day and age should have basic SQL injection attacks, but there clearly are given the number of 'whoops we got our database stolen threads'. Add to that Remote Code Injection, XSS, CSRF, Session Fixation Attacks etc.

One thing I wish that Google would allow is for me to select what service my 1 app password can be used with. For example, I can create a new password that only allows access to IMAP and SMTP for example, but won't allow the attacker to log in to Google Talk...

The trouble with two-factor authentication is that it tends to be a nucleus around which a monoculture of security procedure forms. It is convenient to have a single sign-on that is believed to be beyond reproach, even if that sign on is a bit more obnoxious than the old username + password combo.<p>Until your two-factor system gets hacked, as happened to RSA: <a href="http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-they-did-it/" rel="nofollow">http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-th...</a><p>The more common a security system is, the more attractive a target it is for professional (organized crime) hackers to attack.

Two-factor authentication is a good step, a better one is to completely outsource authentication to a third-party single sign-on provider (Google, Facebook, Twitter). It's a little more work upfront than a standard username/password box, but you get out of a ton of annoying hassles by doing this, including email verification, account suspension, enforcing password rotation/complexity, and building two-factor authentication flows into your app.

If you do add it, make it optional (maybe I don't care that much about my data in your web app). And choose duo, they rock!

We hope to launch a service precisely to help with this (toofactor.com). It's great to see this additional attention and options in the space.<p>Google Authenticator is a great service imho, but I find myself moreso pleased with the 'application specific' password feature which allows me to abstract my exposure even further.

None of these options work for the enterprise and only google authenticator works for B2C. The days of just providing 2-FA are over, companies now need to use an authentication broker, or 2-Factor STS (ping &#38; rsa together or secureauth)

Please don't. I need to secure my gmail because it can be used to request password resets from any account and so is in some way the master key to my online life.

Oh great, so now I get hassled with two factor authentication for every stupid, crummy, brain-dead web app I use? No thanks. This level of security is overkill for the vast majority of apps out there.

If only they had built it with two thousand and one factors of authentication!<p>Joking aside, once you start down the road to two-factor authentication, you might as well go to three factors if you are truly concerned about security. Moreover, at least one of those factors would need to be based on physical properties, i.e., biometrics, or some other intrinsically unique property that can't be forgotten or copied.