Two-factor authentication is a mess
theverge.com
theverge.com
The article identifies 2012 as when the mess started. Oh, no, it goes back at least five years prior. I worked at a company implementing biometrics as an authentication factor. The Feds had just mandated 2FA for banks and the like. Man, we're all going to be rich soon! Nope, I never made a dime off those options, and last I checked the company has pivoted twice and may not even be in business anymore. What happened, we were practically handed a money printing press? What happened was that banks and the like were allowed to use those half-assed implementations like security questions. Yes, security questions counted as 2FA. The "choose a picture" was allowed. So our relatively expensive system was rejected in favor of the less expensive, half-assed systems. And ten years later, here we are, with a bunch of security questions that can be answered by anyone you've friended on Facebook, and SMS that can be social-engineered.
From where I stand, it comes down to money (doesn't it always?). RSA fobs, biometric systems, they all cost money and have high support costs. Because that's what security is: it costs money, and it adds inconvenience. Well, we can't have that, so we'll implement a JS library we found on github, reset passwords over the phone for anyone that says the right things, and we save money.
When I bought I house I drained by savings account and my brokerage account. It was scary that I could instantly transfer my life savings, with just a few clicks from the regular online screens I use each day. Such events should have extra authentication and some delays - like I need to take ID to a branch.
Similarly for domains - if someone wants to change some dns settings - 2FA is good enough. If someone wants transfer the domain I'd like a much higher level of proof including physical mail sent to my address and a month-long delay with multiple confirmations. I'm surprised the cut-throat world of registrars don't compete on this.
How many people go looking for that though? For most people my guess is people go shopping for CHEAP first, EASY second, maybe LOOKS GOOD third, and some where down that list is "much more secure". I hate to say, I rarely go looking for the more secure option of anything.
Hopefully our concept of authentication doesn't slip down the slope so far that we start allowing biometrics for it.
Yes, I had just bought a house. Yes, I had initiated the wire transfer. In fact, I was logging in to check my balance and make sure the transfer had gone out. But it was STILL shocking to see all my money missing.
I've spoken to AT&T numerous times to see what extra steps I can take to secure my account against any changes. So far all that's led to is an eight digit number I have to provide when making any changes. Better than nothing, but something tells me their CS people would still cave too easily to social engineering.
Very convenient!
Do you mean because they only support SMS based 2fa?
Considering they have a drop down menu it's possible they just have not had time to develop the other options?
More than three years seems to me a long development cycle to add TOTP support. Am I being disingenuous to think they just don't care?
That formula would immediately shift if a high profile website registered on Namecheap encounters an SMS hijacking.
The real cost is testing to make sure a code change like this doesn't break existing users and estimating the additional support overhead of dealing with users that lose their two-factor devices.
[1] Seriously the RFC is very straightforward and readable: https://tools.ietf.org/html/rfc6238
Cloudflare supports Authy and Google Authenticator (or any TOTP-compliant app): https://blog.cloudflare.com/you-can-now-use-google-authentic...
EDIT: as pointed out below, there is one briefly on the QR dialog, it's not a separate sheet you generate/download like GitHub/Google/etc
"Your second-factor backup code is 'blah'. This can be used for manual setup, and is necessary to recover your account in case your mobile phone is lost or stolen."
But here's the kicker: Cloudflare were happy to grant access if I could recall some previous name server history for some of my domains. Information that is in the public domain and can be purchased as a report.
This one comes to mind, I think I remember an Amazon-related story along the same lines .. https://www.macrumors.com/2012/08/05/apple-support-allowed-h...
Doesn't make it a the best option though.
I still can't receive SMSs from my Australian phone when I visit there however and always pick up a local SIM for the duration of my visits.
It's not about pricing, it's just that my Australian provider has no agreements with carriers for other countries.
If your carrier is e.g. AT&T you have to sign up for an international service plan or you simply do not receive text messages. The typical thing my friends do is pay $10/day for the international day pass. Crazy. It's why I bought an phone without carrier lock, and when I get to a country just buy a SIM (UICC) with pre-paid texting and data, I don't even car about voice. Since my U.S. number is google voice, the texts come in as data, and local texts are cheap or free in that country.
I'm torn between the insecurity of the cloud and being thankful that all accounts could be restored with ease.
What it means in practice is that when we train people to set up 2FA, we have to teach them a somewhat elaborate dance of enrolling their phone number, adding the U2F and TOTP authenticators, removing their phone number, and then making sure they don't have a recovery phone number set.
They're not insisting on 2FA-by-SMS since you can immediately disable it after you prove that you own a valid phone number and thus is much less likely to be a spammer.
I'm still amazed by how many websites still use this "security question" mechanism. It's almost always the same questions too, "what's your mother's maiden name", "what's your childhood's pet name" etc... It's so easy to get the answers to these questions through the tiniest bit of social engineering, or even just exploring their facebook profiles.
It's crazy how many websites manage to handle auth credentials incredibly poorly, it ought to be a solved problem by now. Last week I created an account on https://www.comedie-francaise.fr/, it used javascript to prevent me from pasting the password in the field (very convenient when you use a password manager, I had tweak the source to remove the limitation). Now that's pretty silly, but what's even sillier is that they then emailed me a password "reminder" in plaintext!
So when so many websites can't seem to handle regular user+password login properly, it's not surprising that 2FA ends up being a huge mess.
https://blog.namecheap.com/authy-based-2-factor-authenticati...
Yes, but your Amazon attack surface just got bigger.
First, is large-scale ATOs. This is, IMO, the real reason why major services implement 2FA. To the best of my knowledge, despite the insecurity of SMS, there's no evidence that an attacker can massively take over accounts of a set of users with 2FA enabled.
Then, there's attacking a single target user. I don't think there will ever be a solution for that, unless the user is really careful. 2FA offers a 2nd factor, but you still need a strong 1st factor to reduce the attacker power.
For example, storing a strong password in a pwd manager is useless when you loose your phone (assuming an attacker can unlock the screen), as both factors are on the same device, making the 2FA de-factor a single factor auth.
Currently, again IMO, the only way to achieve a secure two-factor auth, is to have a strong password that you remember, and a second factor that proves you have a device.
Is perfect the enemy of better here? I would think that having a second factor is probably orders of magnitude more secure than not having one, even if it's a hijackable medium like sms.
When the user makes their first purchase, print out five identical business cards and send it to them by snail-mail. (If you're selling physical products then obviously ship it with the product).
The front of the card is a regular business card; the back says "Use this code for a 10% discount on your next checkout: correct-horse-battery-staple-OTOP-backup-code" and a OTOP QR code.
When the user uses the discount code during checkout, offer them a 20% discount if they scan the QR code and successfully setup 2FA.
This way you "trick" the user into properly setting up 2FA and also holding five physical copies of their OTOP backup code in a fairly innocent looking format.
The user can either:
1. Throw it away. Then nothing happens; no 2FA is set up.
2. Type in the code in for a 10% discount. Again, no 2FA is set up so the user's security is never worst off than before.
3. Type in the code and setup 2FA. This is case the user is tech-savvy enough to properly setup 2FA and successfully authenticate with it (in order to claim the 20% discount) so they (hopefully) realize the importance and convenience of the pre-printed physical backup codes and will (hopefully) stash them away somewhere safe.
The point is that you are basically using an extensible claims-based approach to identity to create "aggregate identities". In the case of a beginner user, it just looks like "my account". More advanced users can add more security as necessary.
The real power of 2FA is having the code generated by you, the human, via your hardware device or software physically controlled by you and not another automated machine.
That's certainly one of the thoughts that I had originally! But if you look at the details, perhaps it will become a bit clearer for you: Each of my email accounts are themselves protected by 2FA, so "those accounts" are not just "protected by regular passwords".
You can have email accounts with multiple email providers, e.g. gmail, outlook, etc. So, depending on how your email account gets compromised, this gives you additional layering of security. If mail provider X has a security breach, no big deal, because you also are using provider Y.
More generally, this can be seen with any factor in authentication, i.e. a claim. If any claim X is compromised, by any particular attack vector, then you also have Y, Z, etc. in play, depending on your security vs. convenience configuration.
And as I stated, email is only one of the avenues used to provide evidence for a claim. In the future, Oauth(2) tokens, sms, etc. The point is that it's an extensible mechanism for genuine MFA, instead of hard-coding in the "2" in 2FA. And that diversity is where the "real power" of multi-factor authentication comes into play.
You can't add N factors to multi factor authentication by adding more accounts. That's just lightly strengthening the first factor (something you know which is a few different accounts) with a splattering of the second factor (those accounts rely on something you have such as your phone). The third factor of something you are doesn't even come into play in this solution.
Having 2FA set up for the account in question makes it reasonably secure. Relying on a second account that also has 2FA enabled does not make it twice as secure. It might make it slightly more secure but not by a lot. It's even likely that the second account is using the same device for the second factor as the first account which negates any added security.
The best you can do in a scheme like this is shift the trust based security to second entity. It's the same level of security but just handled by something you might trust more. (Google/Facebook vs some random website I had to make an account for).
This is an absurd statement that I didn't imply, but perhaps you inferred?
> The third factor of something you are doesn't even come into play in this solution.
As I've said, the point is to allow for additional claims to be given. "Something you are", i.e. biometrics, is certainly "in play" in this solution. It is yet another claim to add to establish an identity. The point is that the identification is extensible, and that it's left to the end user to make the opinions that you're depicting rather insouciantly as some kind of "absolute truth", when what we're actually talking about is trade-offs with security vs. convenience, as well as defense-in-depth.
> It's even likely that the second account is using the same device for the second factor as the first account which negates any added security.
You're assuming that the attack vector is only at the end device. Of course diversification of hardware like a keyfob or smart card is an added layer of defense. But that doesn't mean that there is no value in multiple identities from the same device. It all depends on the specifics of how your device is compromised, or even if it's your device that is compromised in the first place. As I said, what if you have a single email address hacked or a single email (or oauth, or sms, or whoever) has a data breach?
> The best you can do in a scheme like this is shift the trust based security to second entity.
Creating your own user/pass scheme, or your own oauth server is certainly one of the options we have, so again this is not "shifting to a second entity".
I'm wondering if this is just trolling at this point? You're making simply outlandish remarks with numerous assumptions and with little regard to what I'm actually saying.
https://medium.com/@joelrunyon/instagrams-security-features-...
I still much prefer TOTP whenever possible as the phone is potentially vulnerable to social engineering against the SIM provider.
I feel like this is badly phrased. SMS 2FA is far worse than other types, but still better than no 2FA.
It seems like every time I read about how SMS2FA was hacked it was done by some state level power that would've gotten in through some other method. I don't know if that's confirmation bias or actually true, but I think you're right, SMS is better than no 2FA. Just because the NSA etc... can easily break it doesn't mean it's useless right now. (maybe not the case in a year or two?)
It seems to be a lot more vulnerable than that. Perhaps the biggest problem is that the phone companies do not treat your phone number as being a component of a 2FA system (and, to be fair, that was never the intent). This is from the linked article by Cody Brown, "How to lose $8k worth of bitcoin in 15 minutes with Verizon and Coinbase.com":
"Of all the things that went down in the factors that lead to this hack, Verizon Wireless is what I was massively unprepared for. After talking at length with customer service reps, I learned that the hacker did not need to give them my pin number or my social security number and was able to get approval to takeover my cell phone number with simple billing information."
See also: https://krebsonsecurity.com/2016/09/the-limits-of-sms-for-2-...
I think this sums up the problem.
BUT
SMS is likely the most convenient way for non geeks to use. And, as far as I am concern it seems only ( or especially ) Telecoms in US are vulnerable. In places like China / Hong Kong / Japan / Korea, you cant change your recovery code or what ever without your personal ID.
Requiring a physical, government-issued ID to be presented at an office can work for some scenarios, but not for the vast majority of online services.
Recently Google and Lastpass are supporting push notification for 2nd factor in lieu of manually inputting a code. That seems like it'd be more secure than TOTP, but does require an internet connection to receive the notification.
to be fair if you are running the latest android or have an iphone that's probably better than having it all on your exploit ridden PC, but it's still 1FA
https://github.com/w8rbt/oathgen
https://github.com/w8rbt/goathgen1) A completed, signed, and notarized Identity Verification Form and Affidavit 2) A photocopy of the AWS account owner’s primary proof of identification, such as a State driver’s license or US passport. (note that I don't live in the US) 3) A photocopy of the AWS account owner’s proof of address matching the address on record (I don't live there anymore)
in order to stop them from billing me every month for resources I don't use.
I lost my MongoLab token as well, now I can only access my database over a connection string.
Now I don't enable 2FA, the chances of me losing my token are higher than the chances of me being hacked. And after 2 or 3 years I don't remember where my backup tokens are so that's not a realistic option
I'm frankly glad that Amazon are requiring you to go to such lengths to prove your identity to bypass the 2FA and access your account. I think you should appreciate that they're taking the integrity of your account so seriously.
> We recommend that when you configure a virtual MFA device to use with AWS that you save a copy of the QR code or the secret key in a secure place. That way, if you lose the phone or have to reinstall the MFA software application for any reason, you can reconfigure the app to use the same virtual MFA. This avoids the need to create a new virtual MFA in AWS for the user or root user.
That's the nice thing about TOTP[1] ("Google Authenticator"); a single relatively short string can be backed up to later restore access, or you can even print the QR code on a black & white printer.
[0] http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentia...
[1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...
That QR code paper can be secured the old fashioned way: I recommend a fireproof safe. The fact that you'd have to compromise your physical security (either the phone or your safe) and digital security (your password) at the same time provides reliable 2FA.
I'm not a fan of the "back up recovery token" approach, as if you only need the backups once every couple of years, a lot of people (myself included) are likely to misplace, forget where the tokens were.
My current approach is TOTP with sync via iCloud, so the tokens are available on each of my mobile devices, so unless I lose all of them I should be ok.
Of course that provides a weak point (my iCloud account) but there's always a tradeoff somewhere.
It was a huge pain in the ass to go back into all my accounts and get the codes. In many cases, I had to reset 2FA to get the codes. But now that I've done this, it's easy to keep up when adding 2FA to an account, and I no longer have the anxiety of worrying about getting locked out of important accounts.
Another idea I've been considering is a separate password manager account (from a different provider) just for backup codes. It would have a really hard password and 2FA stored on paper.
Your particular situation might be a bit more annoying since all you want to do is close the account, but how does AWS know that? For all they know, you could be a malicious person trying to delete someone else's data.
I use 2FA as much as the next person but I have realistic expectations that it's not a magical fix for everything.