Stripe adds two-factor auth
stripe.com
stripe.com
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.
That's deviously simple.
That's not a problem when it comes to Google accounts, though. Maybe Google's lack of customer support is really a "security feature"!
Google makes is relatively difficult to setup TFA, and you can (and I have) forced a password/TFA reset - took 30m over a couple of hours to restore.
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?
Mt. Gox uses Yubikey for their 2FA.
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.
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?
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 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.
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.
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).
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.
[1]https://news.ycombinator.com/item?id=4916983
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.
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.
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.
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.
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.
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.
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).
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.
A few peeps from my university started Toopher though, looks promising - https://www.toopher.com , since it leverages your phone
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.