After being a WoW user, I think two factor auth only works if it is forced on all accounts.
Here's a scenario that plays out in WoW all the time and it happened to me. Basically, a user quits playing WoW and their account gets hacked at some point after they quit. The hacker then turns on 2 factor auth via the WoW authenticator app. It is now impossible for the original user to log in to the account or reset passwords. To fix this you must argue and explain with customer support that the account was hacked an that the 2 factor auth is preventing you from resetting passwords and such.
So, unless you turn on two factor auth up front for all users, it's going to actually make it worse for the end user if their account gets hacked. So, like captchas, it's solving one problem and creating another for the user. I'm not sure that is the best solution.
I'm a WoW user as well. I will say from experience that you do not have to argue with anyone about removing the authenticator. You simply submit a support ticket containing a picture of your drivers license. The authenticator is usually removed in a few hours. I've done this multiple times now due to formatting my phone without grabbing my restore codes for my authenticator.
> The hacker then turns on 2 factor auth via the WoW authenticator app. It is now impossible for the original user to log in to the account or reset passwords.
> To fix this you must argue and explain with customer support that the account was hacked an that the 2 factor auth is preventing you from resetting passwords and such.
That's not a problem when it comes to Google accounts, though. Maybe Google's lack of customer support is really a "security feature"!
Maybe you don't understand. It takes 0 customer support to add 2 factor auth and lock out the original user. It takes several emails and support requests back and forth to finally get it sorted out. Also, maybe a few phone calls. If that happened to your google account, it would be INCREDIBLY unpleasant.
I was just making a joke, but I was pointing out that if you have 2FA enabled, I could (theoretically) call up customer support and try and convince them that you're the attacker and I'm the legitimate account holder.
Why are people manually typing in keys? The authenticated website could just have an API with a receiving point for a token. A press of a button in a mobile app would unlock the login form for a short period just like a normal 2FA key, only with typing from the user.
You could use the numerical codes as a backup if the mobile device wasn't network accessible, but just being able to "push button" authenticate in a mobile app would make them a lot more usable normally.
Has this already been done, and I just haven't heard of it?
Yubikey is sort of like this. It's a USB key with a small contact on it. It reports to the OS as a keyboard and when you press the contact is inputs a very long string of characters followed by an ENTER. So at the 2FA page you just press the USB key button and you get logged in.
I actually have two around my neck at the moment, I use them for my own hand-rolled websites. They're concienient, but just being able to push a button in an app would be even more so. Not to mention, the backend code they supply on their website is anything but pleasant.
I can't quite see the difference between copying numbers out of an app, and sending a secure string to a server with HTTPS. If anything, doing it in the back end would allow for even longer strings. A signed message or a challenge-response with a large secure asymmetric key.
partly because this is a bit easier to implement, so the barrier to entry is lower.
Also, no network access is required for OATH TOTP tokens to work (they are derived from a shared secret and number of 30s segments of time since Unix epoch) if you are somewhere with no mobile coverage, or are abroad and don't want to pay roaming charges. You can also get hardware tokens for this reason.
Finally, there is no guarantee the network between your mobile device and the web app are secure, and as we've seen with some nation states abusing wildcard SSL certificates, even SSL isn't necessarily a defense.
Yeah, that's OneID and Duo Push, but no one uses it (yet). It's also proprietary, and I think there are some (stupid) patents.
Really, there's already x509, so if you're going to do this all on a single device (a single tablet or phone), just do client-side x509 certs managed well, plus passwords.
The problem was that desktop browsers had the worst possible UI for client certs, so no one used them, so desktop browsers had the worst possible UI for client certs, so no one used them, so ...
1) I'm surprised it didn't happen sooner. There are a few turn-key two-factor auth solutions, and I expect having this added security is a major benefit for their customers.
2) I'm surprised they chose to use Google Authenticator. The favourite in this space seems to be Authy; off the top of my head Cloudflare and DNSimple both use them. Any thoughts on the pros and cons?
There were concerns raised yesterday [1] about the way Authy backs up tokens. The founder's comments initially raised some major flags about their crypto usage [2], but later on they backtracked and indicated that they are in fact using a logical implementation [3].
The major pro is their seed length, which is significantly longer than Google Authenticator. The major con is you have to trust that they are using a secure system.
> The major con is you have to trust that they are using a secure system.
From my discussion with the founder on that HackerNews thread yesterday (and his other comments on the thread), it seemed clear that they didn't have a good enough understanding of the space - both the technical security requirements and the existing solutions. If you're not clear on what problem you're trying to solve, I doubt that you understand the domain well enough to solve it properly - at least when it comes to security.
Security is one field where 80% of the way isn't "good enough" - in fact, 80% may be worse than nothing at all.
> He already stated he was wrong. Do not punish him for wanting to answer fast and be open with the Hacker News community.
First, he was way off the mark on a number of unrelated elements, not just the key-strengthening algorithm.
While it's good that he owned up to his mistake, it's clear from his wording that he was shaky on the actual principles of security and encryption, not just
My standards for a security-sensitive product are far higher than for anything else. Any person in any position of authority should have a very clear understanding of the security fundamentals being used. The last thing I want in a 2FA application is for an overeager PM to make a decision that inadvertently compromises the security of the product, in a well-meaning attempt to improve the UI, branding, monetization, etc.
Product design and technical implementations do not happen in separate silos. And I want the security products that I use to inspire a much higher level of trust than some generic tool.
This looks like it was blown out of proportion. The founder is not involved in day-to-day technical stuff, and he misspoke. It's not the greatest thing to happen to a startup, but it hardly invalidates the whole premise. It's interesting to read that Google's seed length seems to compromise the security of their offering, since most of the replies here seem to be predicated on the idea that Google is doing everything right.
The Google Authenticator key length is truncated because of a usability tradeoff. Initially, a design goal was to allow people to manually type in keys on their device. This would be for cases where you couldn't scan a QR code, like when your device has no camera.
Given the security setting, I am comfortable with the tradeoff. I do not think brute-force attacks represent a significant risk, especially compared to other attack vectors.
That may change over time. Fortunately, it's straightforward to increase the default key size.
This is exactly what happened. Although I am involved in product on 100% of the time, I don't deal with specific implementation details, the engineers working on the solution deal with that. So I tried to be a truthful as possible and answer all the questions I could, I simply got some details wrong. One of the engineers noticed and I rectified my answer.
Details are really important. That doesn't mean I could possibly handle every single detail myself, I can't. We have a whole team that handles different parts of the system and they are fully qualified. In fact the engineers doing this feature did write the correct implementation. I simply made a mistake answering the question.
I think people are confusing the Authy Google Authenticator Support with the Authy product.
We do not sell Google Authenticator or aim to be a replacement for it. We simply added the possibility to add Google Authenticator tokens into the Authy App - mostly since our existing clients wanted this -.
Our Service, it's usage etc are completely separate.. If you are not using Authy you can simply use Google Authenticator App.
The only thing in common is we both use RFC 6238 which is an open standard for Time based OTP's.
Google (obviously), Dropbox and AWS all support Google Authenticator, although Google Authenticator is just one client you can use on the client side.
On the server side, one reason to run this in house is not having to depend on the availability and security of a 3rd party for something as fundamental as logging in.
Most people who care about two factor already have Google Authenticator installed on their phone. Having the user install another app is tedious and a lot of users won't enable two factor because of it.
I think most people who care about it would either (a) already have Authy installed, or (b) care enough that downloading another app isn't going to prevent them.
When it's opt-in you're really not going to get a lot of people saying "Okay, I guess I'll do it if you make it really easy for me." It's either important or it's not. Most folks on HN would probably say it is and enable it as a matter of course, especially for a service with as much business value as Stripe.
> I think most people who care about it would either (a) already have Authy installed, or (b) care enough that downloading another app isn't going to prevent them.
I care, and I have Google Authenticator installed but not Authy.
In fact, it's because I care that I don't have Authy installed - from their comments on HackerNews yesterday, I didn't get much confidence that the Authy folks understand security enough for me to trust them with something this important.
Guy who brought up several of the concerns in yesterday's thread here - and I'm in the same situation.
Actually, I went so far as to download the app just to see if I could crack the backups I was criticizing (i.e., are they actually using a key strengthening algorithm or was the founder just straight-up lying after all of the concern was made public), but when I couldn't get past an SMS-based login-wall to test, most of my initial fears were confirmed.
My concerns and irritations about Google Authenticator also still stand; they half-implemented the spec[1] and have potentially limited everyone's security as a result. However, they didn't misimplement it, so they just limited the gains rather than actually made things worse. I think the QRCode to import the key is, uh, less safe than it could be, but assuming someone hasn't gone and posted screenshots of it to the internet or scanned it with multiple devices, it's not too bad.
I started building a replacement a couple weekends ago to address some of these issues (though primarily because it hasn't been updated to support retina displays, never mind iPhone5), so Authy's timing is rather unfortunate as I've been in the thick of the spec and care deeply about security (I work for WePay; yes, we also have a public rollout of 2FA in the works, it's in internal beta right now). My plan is to give it away for free, if not open-source it completely.
[1] the flexible options for the number of digits, time window, and hashing algorithm are all hardcoded in GA, despite their TOTP implementation actually supporting the full spec. The UI simply ignores all fields beside the label and secret, presumably because they decided to make a screen-wide counter rather than entry-wide. Why it's still forced to SHA1 and 6 digits is beyond me.
> Authy's timing is rather unfortunate as I've been in the thick of the spec and care deeply about security (I work for WePay; yes, we also have a public rollout of 2FA in the works, it's in internal beta right now). My plan is to give it away for free, if not open-source it completely.
I'd be very interested in this, Authy's timing notwithstanding. I think my email is in my profile - please let me know if/when you have something available (whether in beta or general release).
I can't even get Authy to install. I put in my mobile number (why?) and it tells me I haven't registered, with absolutely no indication of what to do now.
> 2) I'm surprised they chose to use Google Authenticator. The favourite in this space seems to be Authy; off the top of my head Cloudflare and DNSimple both use them. Any thoughts on the pros and cons?
Briefly looking at Authy, it seems they do make things reasonably easy. But the pro sides of Google Authenticator is that it's just an Open-Source app implementing open standards. It doesn't require any third parties or network communication to work, and you can add it even to unix logins or SSH.
The favorite in this space is still sadly RSA's shitty SecurID physical tokens (in enterprise). For free/startup/saas things, it's RFC compliant HOTP/TOTP. Authy is one (not quite compatible) implementation of that, plus a management system.
Google Authenticator is the #1 client I see on people's phones, even though it's kind of a zombie project at Google (from what I can tell).
Ugh, please expose the code/seed and just just the QR code. (I usually put the code into a couple of devices manually, vs. one)
Also, let administrators enforce 2fa on all users of an account, and/or see the status of all users of the account. Also being able to enforce password complexity requirements would be nice, but 2fa might be sufficient.
2-factor has a lot of forms, from trusted third party (authy, duo security, etc) to non-networked app (OATH implementations like google authenticator) to smartcards as part of a PKI, to dedicated hardware tokens (RSA/EMC tokens).
They do not suck. Which one is best for a particular need depends on the service and the user.
Toopher's location awareness looks like an incremental improvement on services like Duo. However, it still depends on a third party (Toopher) in addition to the Toopher-enabled website and the user, and it additionally depends on the device having internet connectivity and having location information (GPS, or rough location from cell towers). Some applications cannot rely on a third party; they only want to require trust in the application servers themselves and the user's device, and not trust of third parties (Duo, Authy, Toopher) or network access (internet, SMS). In those cases you need a OATH app like google authenticator, or a hardware token, or, if you don't want to support mobile access, perhaps smartcards as part of a PKI.
The problem with hardware tokens, which are arguably the most secure, is that they don't scale well: you need one per application, and the marginal cost for each one is not trivial. That's fine if you only need one to access your employer's VPN; the employer decides the cost is worth while, and one thing on your keychain is not a big deal. If you need another one for your bank, another for your primary investment account, another for your employer-sponsored IRA, another for AWS, and on and on, pretty soon you need a man-purse to carry them all, and the services that offer them have to absorb the hardware costs somehow. Either the risk mitigation has to make the costs worth it, or else the service will pass on the costs to you, the customer, in some way.
Here's a scenario that plays out in WoW all the time and it happened to me. Basically, a user quits playing WoW and their account gets hacked at some point after they quit. The hacker then turns on 2 factor auth via the WoW authenticator app. It is now impossible for the original user to log in to the account or reset passwords. To fix this you must argue and explain with customer support that the account was hacked an that the 2 factor auth is preventing you from resetting passwords and such.
So, unless you turn on two factor auth up front for all users, it's going to actually make it worse for the end user if their account gets hacked. So, like captchas, it's solving one problem and creating another for the user. I'm not sure that is the best solution.