Two-factor authentication is a mess(theverge.com)
theverge.com
Two-factor authentication is a mess
https://www.theverge.com/2017/7/10/15946642/two-factor-authentication-online-security-mess
111 comments
One thing I'd like is different levels of authentication based on the importance of the action.
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.
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.
I still remember the pit in my stomach when I logged into my brokerage account and saw virtually all of my money gone.
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.
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'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.
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.
agree, we just made a small survey among our customers to learn whether they are looking for more secure way of authentifiction and data storage generally for their work/business (not only our product) and of course almost everybody replied with "yes, definitely, we need more security" and on the next questions about how much are they willing to spend on it, more than 80% replied with "depends on the price", which means security is indeed not in the top priority and is quite price elastic.
It's why I started doing more of my business with Hover.com. I wanted a reliable looking company with 2FA. That was important to me.
I was at Hover and moved most of my domains to NameCheap. The only way I could change my last name on my Hover account was to remove 2FA to prove that I was the owner of the account. No ability to give them a code verbally, etc. Remove, change my name, re-add. It didn't sit well with me for some reason.
When I did this several years ago, it required several levels of verbal verification interactions up to senior account managers at my brokerage. I'm surprised it was so easy for you to do the same.
this is something that my bank is testing on its users now, whether I need to confirm the transaction or cancel my automatic deposit prolongation it asks me to make a photo and send it to them for confirmation, which takes them in average 5-10 minutes. Though it is not a ver comfortable way for an end-customer, I guess some kind of biometric authentication/confirmation will take place as soon as a user will tolerate that.
>> I guess some kind of biometric authentication/confirmation will take place as soon as a user will tolerate that.
Hopefully our concept of authentication doesn't slip down the slope so far that we start allowing biometrics for it.
Hopefully our concept of authentication doesn't slip down the slope so far that we start allowing biometrics for it.
[deleted]
It drives me nuts when sites insist on using SMS or Authy instead of TOTP for 2FA. I get that some users might not be sophisticated or motivated enough to setup TOTP but when somewhere like Cloudflare insists on ONLY using Authy it makes me want to look elsewhere for service.
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.
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.
What annoys me most about using SMS for 2FA is that it's useless if you ever travel to another country and don't have global roaming enabled.
SMS receiving is free everywhere, it has nothing to do with data roaming and generic roaming - available on the network - has been free since I had a mobile phone (~17 years).
Doesn't make it a the best option though.
Doesn't make it a the best option though.
That must be based on a very limited experience. In the U.S. it was common up until maybe 5 years ago for carriers to charge 10c per sent and received SMS. And that's still true unless you have a plan that explicitly makes them unlimited and free (which is admittedly most of them).
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.
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.
Charging for receiving is mad. Are they chargign for receiving letters as well? You can make someone pay by sending sms to them, this is crazy and evil.
Don't know where you are from, but with the company and pre-paid plan I use, I can't receive an Australian SMS from my Australian phone when I'm not in Australia.
Europe, and even in China I was able to receive sms.
MMS is a different story.
China has great mobile infrastructure that, at least from a user perspective, is better than what Australia has to offer (it's significantly cheaper and covers significantly more area).
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.
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.
I don't know who downvoted this; I'm stating facts.
You may be surprised to learn that in some countries (particularly the Land of the Free) the standard, for some weird reason, is for sending SMS to be free and receiving them to be paid.
What ? Definitely no true if you travel cross continents.
There are other companies like Google that first require you to set it up over SMS before they allow you to add a security token.
They do that to prevent account farming. Google is one of the very few companies that refuses to accept my VoIP DID number for 2FA, because they know it's not a "real" number. A wise move, considering that SMS-capable DID numbers only cost a few dimes when you buy in bulk.
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.
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.
This is unfortunate. They presumably do it because people routinely lose 2FA keys, but rarely lose their phone number, and so requiring an SMS backup first cuts down support requests.
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.
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.
We should be just satisfied with TOTP, to be honest. It's just 6 digits by default, and unless you've got good anti-bruteforce protection, it can be broken in a matter of hours to days by just trying enough combinations. I'm sure Google and other big players do a good job of blocking these attacks, but would you trust every TOTP implementation of the web to get that right?
Why do you need a 2nd password when using TOTP? and if you don't then TOTP-1FA should be good enough...
I just consider them as not supporting 2FA. I'm looking at you, Namecheap. My domain registrar not having two-factor authentication in 2017 is preposterous.
I have run into several occasions when I need to urgently sign into my NameCheap account only to discover that the SMS 2 factor auth is not working. (I hit the button to send the code and nothing comes through)
Very convenient!
Very convenient!
Namecheap does have 2fa... https://www.namecheap.com/support/knowledgebase/article.aspx...
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?
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?
As of January, 2014 Namecheap said[1]: "Currently, we only accept SMS authentication but Google Authenticator, Authy, and TOTP authentication are planned."
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?
[1] https://blog.namecheap.com/account-security/
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?
[1] https://blog.namecheap.com/account-security/
[deleted]
It's not that they don't care. It's that $CARE_AMOUNT < $ESTIMATED_COST.
That formula would immediately shift if a high profile website registered on Namecheap encounters an SMS hijacking.
That formula would immediately shift if a high profile website registered on Namecheap encounters an SMS hijacking.
So what's the meaning of caring then? If they aren't implementing the feature, it means that they don't care. It doesn't make a difference to me that they care a bit, just not enough to actually implement it.
TOTP codes are straightforward to bootstrap. It's not rocket science.
At scale the cost of implementing a feature as wide ranging as 2FA is well beyond the tech cost. A basic TOTP implementation can be coded from scratch in an afternoon[1].
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
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
I agree, I wrote an implementation in an afternoon for work, and that was back when there were no libraries to do this for me.
I'll take poor SMS based over none at all.
https://lolware.net/assets/images/netregistry.png
https://lolware.net/assets/images/netregistry.png
I won't, SMS is worse than nothing.
A quick question for someone who knows little about 2FA. If I were to use my Google Voice account as the SMS number does that make it any more secure since it's not tied to a SIM card?
It still goes through a bunch of providers, including Google, so it would not be as secure as TOTP. If the provider doesn't use it as a replacement for the password (ie you can't change your password using it), it may be more secure than just the password alone, but I don't trust it.
thank you
but when somewhere like Cloudflare insists on ONLY using Authy it makes me want to look elsewhere for service.
Cloudflare supports Authy and Google Authenticator (or any TOTP-compliant app): https://blog.cloudflare.com/you-can-now-use-google-authentic...
Cloudflare supports Authy and Google Authenticator (or any TOTP-compliant app): https://blog.cloudflare.com/you-can-now-use-google-authentic...
Thank you, I didn't know this, and it was something I was judging against CF for years. It makes me a little uncomfortable though that there aren't any offline recovery codes in the event the TOTP device is lost/stolen/etc
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
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
Be careful using 2FA on CF. I got locked out of my account because I reformatted my phone and hadn't kept backup codes. That's my fault, not CF's. They wouldn't accept email verification or uploading a html file to the root of my domains to grant access.
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.
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.
Customer Support (well, humans in general) is the biggest threat to security, unfortunately .. :(
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...
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...
You may not even need backup codes. Just save a copy of the google authenticator setup QR code. It's just email/key, when decoded.
Thanks for writing this. I will talk to the support team about it.
[deleted]
There is a backup code.
"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."
"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."
I thought Authy was TOTP?
It is, I use it
it's TOTP, but it backs up your TOTP codes in the cloud and will happily restore them to any device that can receive SMSes to your phone number.
a feature, that saved my ass after i forgot my phone in the rain (yeah, not smart).
I'm torn between the insecurity of the cloud and being thankful that all accounts could be restored with ease.
I'm torn between the insecurity of the cloud and being thankful that all accounts could be restored with ease.
Unless you disable multi-device
It's largely TOTP. IIRC, it's just an additional AND at the end (and selecting 7 digits, not 6).
>The rush to check that box has led to usability problems as well as security problems. Boroditsky points to Apple’s iCloud system, which came under fire after easily guessed account-recovery questions enabled the mass theft of nude photos in 2014.
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.
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.
Namecheap is still the big one that only supports SMS 2FA for me. It has apparently been a big engineering project to add TOTP support so they've delayed it for many (4+) years. They did recently blog they were pausing all other development to add TOTP support but there has been no progress update and their initial promise of "in 60 days" has since passed...
https://blog.namecheap.com/authy-based-2-factor-authenticati...
https://blog.namecheap.com/authy-based-2-factor-authenticati...
I've just moved my domains to porkbun.com instead, since they support TOTP and have equivalent or better prices.
I think there are two big aspects that need to be kept distinct.
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.
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.
>At the same time, it’s proven difficult to kill off particular types of two-factor even after they’re shown to be insecure. The National Institute of Standards and Technology quietly withdrew support for SMS-based two-factor in August, pointing to the risk of interception or spoofing, but tech companies have been slow to respond. If anything, services are relying more on SMS as Twitter and PayPal look to tie accounts more closely to phone numbers. It’s less secure, but easier to use. As long as it’s two-factor, few account holders know the difference.
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.
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.
Please critique this wild-ass idea of mine:
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.
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.
I throw out every business card I get with a package. I never scan the QR codes. I can only imagine the nightmare of recovering 2FA for someone who was tricked into setting it up without really understanding it. Just getting my relatively technically savvy mom on a passowrd manager took some work.
It's fine if the user throws it out. The whole scheme is optional and the code is never activated until the user types it in first.
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 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 problem happens when someone claims the 20% discount, but doesn't understand that they need to keep the card.
I'm looking forward to more genuine MFA. For my site, I'm experimenting with the ability to identify yourself with as many email address identities as you want (in the future the plan is to add more types including oauth, sms, etc.). If you're a regular person, you can just use one. If you're cagey, maybe two or three. Straight up paranoid, how about 10?
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 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.
So instead of hacking 1 email/account they would just hack 2 or 3? I don't think that is adding any real security as those accounts would still just be protected by regular passwords. It makes it a tad bit harder for a hacker but not prohibitively so, because if they got the credentials to your first account then the others are probably not too much harder.
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.
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.
> So instead of hacking 1 email/account they would just hack 2 or 3? I don't think that is adding any real security as those accounts would still just be protected by regular passwords. It makes it a tad bit harder for a hacker but not prohibitively so, because if they got the credentials to your first account then the others are probably not too much harder.
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.
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.
This really does just seem like 2FA with extra steps.
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).
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).
> Relying on a second account that also has 2FA enabled does not make it twice as secure.
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.
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.
Doesn't help that major organizations that use 2FA (facebook / instagram) have had their iterations completely broken (and documented by many, many people) and they still won't fix it.
https://medium.com/@joelrunyon/instagrams-security-features-...
https://medium.com/@joelrunyon/instagrams-security-features-...
I've finally arrived at a pretty comfortable 2FA setup: A Yubikey Neo for TOTP, so I can get codes on any of my devices (including my smartphone via NFC), and a dedicated dumbphone with a worldwide roaming SIM in it where SMS works (and is dirt cheap to receive) no matter where in the world I am.
I still much prefer TOTP whenever possible as the phone is potentially vulnerable to social engineering against the SIM provider.
I still much prefer TOTP whenever possible as the phone is potentially vulnerable to social engineering against the SIM provider.
> Avoid: SMS has been at the center of a lot of two-factor hacks, most recently as a way to hijack Telegram accounts in Iran. High-security accounts are already moving away from it, but a frightening number of services still keep it as an option, giving anyone who compromises your carrier account an easy way in.
I feel like this is badly phrased. SMS 2FA is far worse than other types, but still better than no 2FA.
I feel like this is badly phrased. SMS 2FA is far worse than other types, but still better than no 2FA.
I think SMS 2FA is worse than no 2FA, given that you can often reset a password using SMS as verification. If your phone number is hijacked, you're owned completely. Without SMS 2FA, you have to reset your password via email, or resort to contacting the company directly.
If you can reset your password with it, it's not a second factor. It's just a different factor.
But there needs to be a scalable way to let users reset passwords. Users will forget passwords, as anyone who has ever worked tier one support can verify.
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.
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.
Too bad this is a sub-comment that can't be voted to the top of the page. Very insightful, and a way of looking at the situation that I'm disappointed to say didn't occur to me until reading your comment.
>> 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 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 like every time I read about how SMS2FA was hacked it was done by some state level power...
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-...
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-...
> It seems like every time I read about how SMS2FA was hacked it was done by some state level power...
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).
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.
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.
Every hack I've read about is based on social engineering and is enabled by weak policies and overly helpful customer service representatives at wireless companies.
Yes, to the point where YouTubers get their accounts hijacked so often that it's best practice among them to use a secret burner phone for 2FA
What I don't like is everyone using different 2FA standards, so you end up having to use different apps to find the code for a given service.
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.
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.
people's phones have their passwords from their google/firefox accounts, their email, and tend to be their 2FA device for google authenticator... not really 2FA anymore
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
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
Having a secure way to log in to your phone is supposed to be the second factor.
Got to use TOTP or FIDO (U2F). Can't rely on SMS (SS7) attacks. Here's some TOTP/HOTP software I wrote:
https://github.com/w8rbt/oathgen
https://github.com/w8rbt/goathgenI lost my 2FA to AWS (my phone broke), now I have to provide:
1) 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
1) 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
Good! That actually makes me feel really good about their policies. Weaker ID requirements result in people social-engineering their way into other people's accounts.
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.
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.
This is why properly implemented 2FA provides backup codes when you first set it up.
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.
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.
I only enable 2FA if it's TOTP or HOTP. In the case of TOTP I save the key (the data in the QR code) in my password manager (KeePass), in the case of HOTP my backup key is in my fireproof safe at home along with other important documents. That's admittedly a small portable box with a carry handle, so easy for a burglar to steal, but it's also easy to get to and I can take it with me if I ever have to evacuate or move.
Saving the 2FA key along with your password makes it a single factor. I just add every new key to my Yubikey (as well as FreeOTP on my phone), so I have a backup if one breaks (this is on top of the backup codes).
I just made a couple of copies and stashed one in my house and the other at work. If the entire metro area burns down I'll be SOL, but for reasonable levels of disaster I should be able to manage.
To quote the AWS ManPage[0]:
> 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...
> 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...
My standing recommendation is printing that QR code on paper and not keeping any digital copy of it, as it does function like "your second password" for all intents and purposes. You really don't want your 2FA tokens synced anywhere online, or stored on any device someone could potentially break into over the Internet.
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.
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.
The nice part about AWS MFA is that there's usually multiple people with IAM access. So rather than use backup codes, we rely on co-workers to help us resynchronize. It may not work for 1-man shops, but how many AWS accounts only have 1 admin?
you should always have at least two keys (devices) just as you always have at least two sets of keys to your home or car. same for u2f tokens.
Coincidentally I set up 2FA on Amazon yesterday. I am disappointed they do not give you backup codes, nor do they support FIDO U2F. I made sure to keep a copy of the secret token in case anything happens to my phone I can set it up again. The way I do it is to scan the barcode in a reader first, save the token, then scan it in an authenticator app to install it.
The failure modes of 2FA and what happens when a token is lost or breaks are definitely one of the pain points.
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.
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.
I got a $20 fire-resistant lock box just to keep my backup codes in, written down on index cards.
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.
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.
Completely unrelated to 2FA... but what kind of fire-resistant lock box did you get? I'm looking into something like this for the same reason.
For me I opened a ticket and they verified few questions and address on phone and was cleared on 2FA , in fact I wiped my phone forgot about gauth few times had no issue with aws
> It was supposed to be a one-stop security fix.
I use 2FA as much as the next person but I have realistic expectations that it's not a magical fix for everything.
I use 2FA as much as the next person but I have realistic expectations that it's not a magical fix for everything.
The big problem is no so much that 2FA is broken but bitcoin makes breaking 2FA so much more lucrative.
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.