tl;dr: You ought to be using 2-factor, and you ought to be using the one-time password generator built into 1password instead of using SMS.The "SIM porting" attack has been becoming more common and getting more press recently. Basically, it's easy for a crook to call up your phone company and get them to move your phone number to their phone. The telco is supposed to verify that it's you requesting this, but they are stupid and easily fooled.
Once the attacker is receiving your text messages, most services, even those that use 2-factor auth, will allow them to do a password reset and take over your account. My understanding is that they generally needn't have also compromised your email account first.
The fix to this is to not use SMS for your 2-factor. A better way is to use a one-time password generator. There are physical-dongle versions of these, and software versions. The way they work is, set-up involves them sharing a secret by scanning a QR code; and then the login codes are generated based on that secret, without the two ever needing to communicate again. Basically it's a clock-based PRNG with a shared seed.
Many people recommend Google Authenticator and I gave that a try, despite a deep paranoia about any software that has "Google" in its name -- which is not helped out by the fact that Authenticator was once open source, but then Google took it proprietary, which is not at all a shady and concerning move, no sir.
The problem with using that app is that if you want to use more than one device to generate your one-time codes -- say you sometimes have your phone with you and sometimes have your tablet with you but not both -- then you'd have to set them both up at the same time. You can't add a device later without losing access from all previous devices.
But it turns out that the excellent 1password includes a compatible one-time password generator that does the same thing! Instructions here. The huge benefit of this over Google Authenticator is that you can access the code generator from any device to which you are syncing your 1password vault, including your desktop.
This works with Facebook, Dropbox, Twitter, Kickstarter and Etsy.
Instagram (owned by Facebook) say they're really thinking about supporting non-SMS 2FA, really thinking about it really hard. But they still provide 2FA only via SMS.
Patreon and Ebay also only support 2FA over SMS. (Oddly, it looks like Patreon used to support OTP but stopped??)
And Twitter, of course, goes out of their way to fuck up this security feature, as is their core incompetency.
- You can't enable 2FA at all without giving them a mobile number. You have to enable 2FA with SMS, and then you can switch to OTP.
- After you've configured the OTP, you also have to go into the SMS setting and say "no really, don't use SMS for 2FA". Because if you don't do that, the login page will still have an option that says "Choose a different verification method" that allows your friendly neighborhood hacker the option to use your phone number anyway.
- Just remove your phone number? Oh ho ho ho, no. Doing so turns off 2FA entirely.
Kickstarter seems to have the same bug: you can turn on OTP but you can't ever turn off SMS.
Amazon is even weirder: they let you register an OTP app, but I can't find a way to make them actually use it. They always use SMS.
In short, everything is terrible and it's a wonder that you can still log into any of your accounts at all.
Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.
You can use more that one device with Google Authenticator. Just save the QR seed in an encrypted zip file or something.
1password is basically doing just that, but storing your password and seed in the same place kinda defeats the purpose of 2FA.
Wow, that's a real fine user interface you got there. Very usability much crypto wow.
So instead I should use Google Authenticator and that's safer because GA is on my phone, whereas my password vault is... on my phone.
There's an iOS app called 'OTP Auth' which seems to be compatible with everything and which seamlessly shares details by iCloud. That worries me slightly (has the person got the encryption right?) but not as much as using anything made by Google who I just assume are 'anonymously' recording the things you authenticate to. There's a Mac version of OTP Auth but I already use something else there (OTP Manager I think) so I haven't tried it yet.
I'm not claiming these are preferable to 1password but they are other non-google options if you don't already use it.
Yeah, Authy also apparently has some way to store your OTP seeds in the Clown. But I already use 1password, and they seem to know what they're doing.
Amazon leaves the SMS loophole permanently open (boo!), but I have succeeded in getting it to use TOTP-generated passwords when logging in from "unfamiliar" devices or whatever combination of IP, client, location, etc trigger their "let's ask just to be sure" detector. Signing in using Incognito/InPrivate/Private Browsing always prompts, too. https://www.amazon.com/a/settings/approval has a "Devices that don't require codes" section, and a button labeled "Require codes on all devices" which presumably nukes all device approvals. If you have this section presumably OTP is enabled per Turning on Two-Step Verification which I assume you did already to get set up. I also recall having to sign in once using an OTP to fully enable it.
I have "0 devices that don't require codes" but no "require codes on all devices" button.
It says "Preferred method: [my phone number], Backup methods: authenticator app", and clicking the "Change" button next to "Preferred method" just lets me change the phone number, it doesn't let me change which method is used.
I wouldn't expect the Require Codes on All Devices button to be present until you have a non-zero number of devices that don't require codes.
Do you see "Two-Step Verification" "Enabled" on https://www.amazon.com/a/settings/approval ?
I don't recall going through anything other than the usual "add new key to Authenticator App via QR code", "prove to us it worked by logging in with an OTP"
How do I enable Two-Step Verification on my Amazon account? from Audible has more info on changing the preferred auth method but it seems like that is part of the auth app enabling flow? Sorry, it's been a while since I enabled it and recall it was made preferred as part of using it the first time.
Yup.
And it is doing 2FA -- just always with SMS, never with OTP.
Huh - just a few minutes ago, I was able to enable an authenticator app (OTP Auth) with Amazon, then successfully switched my "preferred" second factor from SMS to the app by clicking a link which was prominently displayed beside the "Preferred" header.
I logged out, then logged back in - and it indeed prompted me for the code from the app, and did not send a text.
So perhaps they haven't rolled it out to everyone yet... but, for me, it worked the way I would expect.
Hi jamie, I know this is an old post but I was just digging into this since I had some weird activity on my account. I had the same problem on my Amazon account - I added the authenticator app (1pass) but couldn't figure out how to make it primary. I disabled 2fa and then when I re-enabled I was able to make the authenticator app the primary method.
Amazon works fine with OTP - but I think they don't have my phone number, so perhaps that why they don't offer SMS for me? And I remember I had to enable OTP via amazon dot com, not our localized version here, 2FA wasn't available in their interface. Here's the german "manual" (with pictures) for that - nearly three years old, so things might have changed: https://heise.de/-2965600
IMNSHO WebAuthn is what we actually need here. Bake the long term secret inside a physical object. Bad guys sophisticated enough to hijack SMS are sooner or later also going to either break in and steal all the data out of someone's 1password or socially engineer them into disclosing it. But stealing a hardware token demands a whole different skill set, and one we already understand how to defend against.
The UX isn't horrible either. Tap security thing to log in, makes sense. I can teach my mother to do that, which is more than I managed with password managers.
It's also elegant cryptographically, each token is unique but fairly dumb, if I merely find a random token (maybe left on a bus) rather than stealing one, I can't use it to impersonate anybody (since I have no idea who to impersonate) but it's not useless, I can use it myself. So unlike with old-fashioned RSA-style OTP fobs it's not made into trash by being lost, it's like a dollar bill in this respect. I may not be able to track down whose dollar it is, but never mind it's my dollar now and I can use it.
I don't need another physical piece of junk that I have to carry around with me all the time, though.
Also I have come to realize that modern young adults are incapable of retaining physical possession of the same phone for more than 12 hours. Seriously, you wouldn't believe how often we hear the excuse from soon-to-be-former employees, "Oh yeah, I no-showed for my shift because I lost my phone, and [...more traditional bad reason...]"
It's definitely true that some people are only not losing their heads because those were physically attached. Although I am now an old person and so maybe I have no clue, my impression is that their peers do still regard these people as a liability - I think they're basically the same people who were hopelessly unreliable when we were kids, but we didn't have a $500 supercomputer small enough to leave on a bus by mistake. They're Sharif, the grad student in Rainbows End, they are't bad they're just hapless. Or lazy. Or both.
I wasn't interested in carrying tokens plural, but it's like the No Homers rule, one token is allowed, it's on my key ring. And I have nicer, bigger tokens... in a locked desk drawer where I keep those one use OTP override passwords.
Obviously the only correct solution is a chip embedded in your right hand and another one embedded in your forehead for good measure. After all, you might lose your hand. We have Google brand, and we also have Hello Kitty brand for the pussies who don't want to sell their soul to Satan. As a bonus, you don't have to carry and potentially lose your credit card any more either. Trust me, it'll be great.
Do you have to touch the chips together to make them work?
There is also Authy which is an app (and chrome extension etc) specialising in 2fa, and has the usability features expected like multi-device support, backup and recovery etc. That aside their web site in the 2fa guides section does have illustrated screenshot guides on how to turn on 2fa on various popular sites.
Also having success with Authy. Drives me into a blind rage that my.gov.au supports TOTP through... their own custom app, whose token I can’t export.
There is also an app call FreeOTP, Apache licensed, for Android and iOS.
I had, in my head, configured Twitter for 2FA long ago, but when I visited the profile page on the site, it only showed a "set up 2FA" button, suggesting that I had done no such thing. Now that I've set up 2FA, that button... still shows up. It's like they're not actually committed to the whole 2FA thing, really.
Additional (local?) weirdness from the Twitter app: I'd have poked at this via the Twitter app, except that I can't actually access the "login verification" page. Profile -> Account -> yadda -> Login Verification -> app crashes. 100% consistent.
I took care of most of this by deleting (as best I could) my Twitter, Amazon, Instagram and Facebook accounts. Easy peasy!
+1 for 1Password, though. Solid piece of software. The only thing I currently use that I didn't delete immediately when they changed to a subscription model.
We have been using voice calls for the 2nd factor instead of SMS. The server calls the user and requests a PIN. So stealing the phone number isn't sufficient to gain access, the intruder would also need the PIN. That would be pretty hard to get, since the phone network is so logically separate from the Internet. You might think that the PIN could be stolen by social engineering, but the user whose phone doesn't work is likely to be suspicious of a request for his PIN!
Actually, the fact that Google authenticator is kind of a bitch to move from one device to another makes me trust it more.
The shared secret is the basis of the authentication there. It should not be possible to share that. That's less secure. New device? New secret. It's the only way to be sure.
Oh, the reason they went closed was because they wanted to add in a less secure method specific to Google services.
If Google knows your device, and you log into one of their properties, and you use GA, then it does a notification to your device with the Approve/Deny button thing. For the other normal type in the code methods, it's the same as it was.
"The security of this mechanism relies on nobody seeing the source code" should be setting off screaming klaxon alarms.
You're not wrong. But given the fact that they added a lesser security mechanism specific to their properties, and yet it's still a PITA to transfer that data to other devices without redoing things, well, I know how that works. I still trust GA, and don't trust systems that let me save my shared secrets in "the cloud".
LastPass has a similar system for 2FA and transferring devices. I don't use it because I'm still unconvinced. I say this as somebody who has read the source code and understands the math and encryption methods used.
That said, the fully open source code projects that just implement the math and don't have a way to avoid tying in the 6 digit code are perfectly fine and will work forever. The type in the code thing is the most secure way, and the standard. That will remain supported.
The only reason GA went closed was to add in that ping thing, where they could avoid the "type in the code" bit, at the cost of real security.
Any method that requires an active 2 way connection can be hacked. Somehow. The standards don't require any network connection at all. TOTP is secure without connection.
Eventually, I will give 2FA a try, but just about every scheme assumes that no one can steal my phone. Maybe they can't. Who reads all those damned release notes anyway?
If they have to steal your phone, then they have to be targeting you directly, rather than sweeping you up in some bulk exploit harvested from the back end. So that's something.
Then they have to unlock your phone. Which isn't impossible, but not trivial.
Then they have to crack the password protecting your OTP vault (which 1Password has but oddly Authenticator does not). So that's another impediment.
Every layer makes it harder.
Twitter's 2FA implementation managed to go the extra goddamn mile in total failure, in that they now support a FIDO/U2F key (aka yubikey)...
...A u2f key, singular. You can add one and exactly one u2f key to your twitter account, and that by god is it. Which suggests that they farmed the task out to an intern somewhere and that literally nobody involved in this process actually understood what they were doing.
I don't know about U2F, but WebAuthn (which if anybody reading is thinking "Oh, Security Keys seem like a good idea", WebAuthn is what you ought to be implementing today not U2F) is very explicit throughout about the idea of doing multiple registrations for a single user, so that even aforesaid Intern ought to have thought "Huh, why am I only allowed one?"
On the other hand the "I have no idea what I'm doing, but I implemented everything as described in this ticket" model appears to explain almost all of OpenSSL, and Apache httpd's implementation of features like Stapled OCSP. Nobody who had any idea what this mechanism is actually for would even bother implementing a feature that staples error messages, let alone making it the default. Likewise for replacing an old but still valid response with an invalid one that's newer.
Yeah, WebAuthn inherited the same model from U2F. The whole goddamn point is that the user can bind as many hardware tokens as they want to the identity so that they can have one key in the usb slot of their laptop, another one in their work desktop, a backup key on their actual keychain, and a backup-to-the-backup hidden under their floorboards or whatever. (And hopefully eventually stored in the secure enclave of their phone so that they can stop carrying the stupid key fobs around.)
Restricting it to one key is basically saying, loudly, "we had a compliance checklist that required that we support this, but we really don't want to so we're going to make it useless in the real world."
My bank supports 2FA "only" via the Symantec VIP Access software - which is standard TOTP under the covers, apparently.
After some fooling around, I was able to generate a valid TOTP URI I can store in 1Password and which works on the site using this:
https://github.com/zecoj/python-vipaccess
(I had to make a minor change to the software - replacing the 'VSST' prefix with the one my bank seems to want, SYMC)
I am no-joke jealous that your bank supports any form of TOTP auth, even with an implementation as crack-addled as that. I suspect my poor benighted little credit union will get around to doing this somewhere shortly after 2055.
I self-owned by having any use for PayPal in the first place, but for the record I can confirm that PayPal also limits users to only SMS-based 2FA. There are lots of reasons to never use PayPal and that is one of the lesser ones, but just FYI.
There is a rationale for this, but I do promise that if I ever get a butler whose professional time is solely dedicated to my errands, I will bankroll my principles & cut PayPal out of the equation.
Maybe this isn't true any more, but it at least used to be that if you ever reached some lifetime total of money-spent-through-paypal (and it was low, like, a couple thousand dollars) then they wouldn't let you spend money any more unless you gave them bank account info instead of using a credit card. I assume this is their way of dodging credit card processing fees -- but that also means they dodged the credit card processor's chargeback protections, and I sure as shit don't trust PayPal with that decision-making.
So ever since then I have never logged in to PayPal and when there's a vendor where that's the only payment option, I just enter my credit card number manually every time and say "no thanks" to the create-an-account up-sell.
Fuck those guys.
This is probably true because I did, ultimately, hook a checking account into it. I'm a little more fatalistic about finances than most people & the trust factor is relative (apparently I live in "skimmer heaven" and my credit cards were getting hacked and auto-cancelled every 6 or so months, so using CC info for recurring payments was becoming a horror). But, indeed, that's a serious threat vector if I am looking to not-get-owned by a vendor.
Virtually all of my PayPal activity is not one-off, it's recurring charges or consistent-order connections with major retailers. That's a slight mitigation.
However, upon review, there is one change I need to make, a certain car-ride vendor who nobody trusts & I signed up with incidentally & I use infrequently & I should probably cancel altogether (except, they have some sort of deal with my employer and I am obligated to at least attempt to use them for business travel), they have a PayPal authorization and I realize I should have a much, much stronger firewall between those bastards and my bank account. The threat is not merely theoretical, they are actually facilitating "vomit fraud" now on top of the many, many ways they have found to cause pain on nearly anyone who attempts to do some sort of business with them. They, of any company on earth, should DEFINITELY not have permission to "charge first, settle grievances later".
Oops... case in point: