

Want to be more secure? Build two-factor authentication into your webapp - ashamedlion
http://blog.alainmeier.com/post/28914464388/want-to-be-more-secure-build-two-factor-authentication

======
bithive123
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-...](http://it.isevil.org/blog/2011/11/13/authentication-service-
using-google-authenticator/)

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.

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

~~~
jwbaker
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.

~~~
pavel_lishin
"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!"

~~~
nilsbunger
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.

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

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

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

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

~~~
X-Istence
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...

~~~
laurencei
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...

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

------
X-Istence
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...

------
jamesmcn
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...](http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-they-did-it/)

The more common a security system is, the more attractive a target it is for
professional (organized crime) hackers to attack.

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

~~~
arunoda
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.

~~~
sporksmith
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.

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

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

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

~~~
jonknee
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).

------
krosaen
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!

~~~
sriramiyer
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?

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

~~~
rdl
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.

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

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

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

~~~
Jach
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.)

