Want to be more secure? Build two-factor authentication into your webapp | Hacker News Reader

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

blog.alainmeier.com

59 pointsashamedlion40 comments

I think the better advice is to completely decouple your authentication from your web app, and then add two-factor authentication to that.

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: http://it.isevil.org/blog/2011/11/13/authentication-service-...

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.

The solution to security is to come up with better and innovative security solutions.

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.

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.

[^1]: simply a HMAC / hash value using both the biometric data + the domain being authorized would deal with privacy concerns.

I'm not a fan of biometrics (I have a fingerprint reader on my laptop) because you can't change your password once it's stolen.

The "Log-in with your iPhone?" could be coupled with some kind of non-biometric authentication and that would be better. But honestly, two-factor with strong passwords are more than enough. The dismal security scenario is mostly cultural, not technological.

Oh yeah, that'll be way more convenient. Right up until you need to login when your phone is out of batteries, not in wireless coverage, under water, etc.

"I wish I could log in and check my account balance. If only I hadn't burned one finger, and got a cut on the other!"

I had this problem when I was applying for US citizenship. I was on the crew team in college, which means I had callouses all the time on my fingers, and thus blank fingerpads.

I applied for citizenship 3 times over a period of 3 years, and each time got rejected due to poor quality of fingerprints.

Finally I stopped rowing and then got my citizenship. I'm sure there's some way around it, but it was kind of amusing and frustrating at the time.

Make a mold of someone else's and then wear those to your stamping.

This argument is a tautology -- "make secure security less annoying by developing new less annoying but more secure approaches that will not be a barrier to user adoption and ignoring implementation complexity"... hmmmm.

"log in with iPhone" button" - that almost sounds like Two-Factor authentication...? :)

Seriously - how is that any different than turning on your iPhone and clicking on the Google authenticator app to get your code?

That cryptographic "login with iPhone" thing has been done, albeit without the biometric dimension you've suggested. http://www.ekaay.com/?lang=en

Unfortunately the SDK is only available for PHP & mysql.

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 (http://news.ycombinator.com/item?id=4348475)

Who says it's optional? I make primarily B2B web apps, it's very easy to require all users begin using two factor auth.

of course the issue with 2 factors is that:

- 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)

- its quite annoying to use

- it doesnt solve everything, only weak passwords/brute force

- it locks you out if you lose your phone/token until you get back home to get your recovery keys

- compromising the phone (2nd factor for the general public) allow compromising both passwords and the authenticator

and the issue of passwords managers:

- they're stored everywhere because you need them (incl. your phone)

- you have a single password to decrypt them all

- compromising the phone, once again, give you all passwords, and the authenticator

How does compromising the phone compromise the password? I turned on 2 factor auth and the only thing that would be compromised is the code generated by the 2 factor auth. My password is still secure in my head.

My password doesn't get used for anything, all my applications have a 1 app only password.

An attacker would still need my password...

I think the issue is most people have email on their iphone, so you can send yourself a password reset to your phone, get your password, then use the code also generated on your phone.

Personally I have a pin on my iPhone - and I have my iPhone set to 'reset' itself if there are 10 incorrect pin attempts - so even if I lose my phone, I doubt they would get in...

what do you think happens, when you type the password that's safely stored in your head, onto your phone?:P

Of course it doesn't solve everything, but it raises the bar. Social engineering is an active attack that doesn't scale like phishing; the support folks at the organization will catch on a whole lot quicker than their users.

> compromising the phone (2nd factor for the general public) allow compromising both passwords and the authenticator

Unless I've misunderstood how 2-factor authentication works, this is misinformation. The entire point of 2-factor authentication is that you need _both_ factors; i.e., having only one does not compromise the system.

Except in practice you have both factors on the phone (unless you don't use the phone for anything else than .. phone and an authenticator? that just never happens)

so, no, you just need to think about it a little while longer.

> Except in practice you have both factors on the phone

What do you mean by this? I'm not doubting you, but I'm still a bit confused -- currently taking a Security course, so I'm a newbie in the field.

Do you mean that if the phone is compromised (and you don't know its compromised) that once you input your password (the "what you know") the system is broken? Certainly, I can see that.

I may still be misunderstanding, but if you don't store your password(s) on your phone, then does it prevent this attack?

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.

Until your two-factor system gets hacked, as happened to RSA: http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-th...

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.

No it's not better. If one'e Google Account get hacked. hacker can access all the sites, including yours. SSO offers good UX but not the security.

Isn't this typically the case anyways? A hacker with access to your email account can just use the password reset mechanism to get a sign-in link to your other web sites.

Yes! It is the typical situation. That's why 2fac auth comes in.

"Have email, lost phone- help me" -Mallory

Well, it leans on the fact that it is more likely that Google has good security and that your web app will probably never reach that kind of security. It also works the other way around, someones Webapp gets hacked (which is far more likely) and the same password is used for google, you get the same end result, but then it is YOUR fault, and not google's.

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!

I second the recommendation for Duo. Know them personally and yes they do rock!

Implementations like Duo help only if you're the service provider, right? As a user, independent of the service provider is there anything I can do?

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.

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.

Unfortunately those application-specific passwords aren't particularly application specific, at least in Google's implementation -- any of them can be used for anything.

If someone built a system which could restrict passwords or keys by some kind of capabilities (e.g. my Adium gtalk password could only be used to authenticate to Google's Jabber servers), that would be useful. It would be complex to manage, especially as your applications change over time, but not impossible.

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 & 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.

There are plenty of other apps you want to keep as secure as possible. For me it's: web hosts, DNS providers, Dropbox and source control hosts (GitHub/BitBucket).

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!

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.

It's only n-factor if you have n orthogonal keys. Typically "something you know", "something you have", and "something you are". In the same sense that two passwords isn't "2-factor", I wouldn't say that a finger print + DNA sample is "2-factor". The problem with "something you are" as a third factor is that it typically requires you to have some hardware to get that information, in which case it's just 2-factor again. And if we get the technology to read out brain dumps, knowing a password is just a part of something you are and we're back to 1-factor... Which suggests it's not the number of factors that are important, but the total number of bits of information involved and how hard it is for theoretical attackers to gather all those bits. Is your scheme torture-proof? I doubt anyone would prefer torture over handing over their phone+password to their gmail account. But most attackers aren't going to come torture you. A phone or a yubikey or what have you is immune to OS keyloggers which defeat passwords of any complexity, that alone makes them useful against a big class of attackers. What class of attackers does e.g. a thumbprint further defeat? It sounds like it's more useful as a reset verification than anything else--you can forget your password and lose your phone but you don't lose your thumb--usually. (We can also get the 'mark of the beast' and have chips implanted in our hands.)

Reply on news.ycombinator.com