I am forever worried that if I sign myself for 2FA in 50 different services and then I lose my phone I may permanently lose access to my accounts.
I am forever worried that if I sign myself for 2FA in 50 different services and then I lose my phone I may permanently lose access to my accounts.
This is the usual security versus convenience problem. The site is forcing you to use an additional factor, but there is flexibility in how that is serviced. Choosing convenience may open paths for attackers, but the impact depends on your threat model.
One solution with Google at least is that they basically hardly ever require you to reauthenticate on a given device but that obviously doesn't help if the device in question breaks or is lost and is also your soft token.
As you say, not an easy problem. The happy medium depends on the threat model and is somewhere between being able to easily social engineer new access and having to show up in Mountain View with a sheaf of notarized proof of identity documents.
I tried to do this during the pandemic and the local bank branch didn't have anyone who could give me the right authentication so I had to spend a couple hours going to my local brokerage office to complete a transaction.
You are able to give away your password to bad guys, it's really easy because it's exactly like just using the password normally except whoops this was my-bank-login.example and not my-bank.example/login or login.my-bank.example or whatever the URL usually was.
WebAuthn fixes that, everybody should implement and use WebAuthn. To their partial credit RubyGems apparently noticed they ought to do this, and so this message says they're working to implement it.
It's also "very easy" to be traveling, lose your passport or ID and not have a backup with you. Or to accidentally leave your house and forget your keys inside. Or any other number of comparable scenarios.
When that happens to you, it sucks, and you will have to jump through hoops. But still that doesn't mean that passports and keys aren't valuable in terms of security.
Of course, the difference is that people understand the value of passports and physical keys, but by and large they fail to grasp the importance of IT security or how to protect themselves. This is, ultimately, an education problem. But we don't have the same internet anymore as 20 years ago, and the problems associated with identity theft, unauthorised access, etc. are much bigger than they were, so we can't afford to be too cavalier about it anymore.
Maybe, if people get locked out of their google account because they lost their recovery keys, they will in fact learn that, yes, they should have printed out their recovery keys (something which you are prompted to do), or stored them in an otherwise safe location (e.g. password manager).
Except there may not be any hoops to jump through with MFA if it is "too secure". See "I've locked myself out of my digital life" (a thought experiment):
* https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my...
* https://news.ycombinator.com/item?id=31652650
> Maybe, if people get locked out of their google account because they lost their recovery keys, they will in fact learn that, yes, they should have printed out their recovery keys (something which you are prompted to do), or stored them in an otherwise safe location (e.g. password manager).
Except at that point it could be too late and they've lost all access to their digital life/assets.
The difference is I can physically show myself at the embassy or consulate. I can ask a locksmith to come to my place.
I can't do either when I lock myself out of my Gmail account.
Apple is going to start rolling this out in iOS 16 and I expect many sites and platforms to implement support relatively quickly. It’ll take time for this to work its way through the ecosystem and there will still be some trade-offs that will lake someone complain, but this is one of the more promising initiatives in the “passwordless” world that many security professionals have been striving for for quite some time.
I do think that when it comes to software/package maintainers, the heavy lift of having to have an MFA solution is much smaller than for a regular user. Yes, you need to store your one-off keys somewhere safe (I use a password manager and store it in an encrypted file there whether that counts as a second factor or not is debatable, but I think the fact that my 1Password account requires an account key as well as my password when accessed from a new device helps protect against unauthorized access at least), but I do think this is an acceptable trade-off (for now) if you’re maintaining a popular OSS package.
Maintainers have to do a lot of janitorial work, it’s true. And it does often fee unfair. But I don’t think asking people who maintain popular projects to use MFA for their package system is too much.
> Many services seem to offer one-time codes for storage offline in case this happens.
Adding on: even password managers like 1Password [1] and Bitwarden [2] offer support for TOTP 2FA now.
But a good single factor is probably fine.
If only everyone would use Oauth rather than hiding it behind 'enterprise' plans...
I use this approach with Yubico Authenticator, which stores its data on Yubikeys, so I have all 2FAs on at least two keys even with TOTP-only services that seemingly allow only one authenticator per account, e.g., AWS.
I have a _separate_ KeePassXC database where I store the original OTP secret (if you click "add manually" or "can't scan", etc when the QR code pops up... it will give you the secret that's in the QR code) and recovery codes.
If I ever lose my phone/yubikey/etc, I can go unlock my "break glass in case of emergency" database and access accounts directly or recover from there.
I keep this in a separate database versus, say, just putting the password + OTP secret + recovery codes all in the same Bitwarden vault because I want to maintain the full security of the second factor. If my e-mail and password for Bitwarden is enough to get you the username/password/otp then I figure it's really only protecting against credential stuffing.
I'm having a prepaid plan with att, and I did not pay it for a while. Recently I needed to get a text message so I went on the att prepaid website to reactivate the plan for the month so that I could get the text message.
Guess what. The att website wants to send me a text message to ensure that I am the owner of the account... to my phone... that has no plan... fun times!
The same applies to prepaid cards - if the balance hits zero, you can only do incoming calls and texts.
Obviously, the provider will still send debt collectors if you were on some fixed price per month plan, and those debt collectors will still try to collect moneys for the months the service didn't allow outgoing calls... I always thought it odd that a company was allowed by law to collect money for a service they didn't provide.
There's also the model where you pay a monthly subscription and receive a new device every few years or have some other benefits.
In which case, I wonder if I actually just lost my phone number altogether(?)
1. Buy a sim card from ALDI for 10€ 2. Activate 3. Use the phone until the balance is down to 0€
At this point you've got an empty balance, are unable to make calls or send texts, but you can receive calls or texts still just fine. You can also visit zero-rated websites (in the past e.g. 0.facebook.com).
When I was a child my parents would give me a phone with a SIM card in this state, they could still call me if they needed to tell me to come home, and I could still call the emergency services, and given WiFi I could surf the open web as well, but I couldn't waste money on paid services or calls.
Incoming texts will also be rejected and not delivered. In other countries (I know about Ireland, anyway) this isn't generally true.
That's why I originally said it was weird to me as somebody outside the US.
This is bizarre to me. I wouldn’t expect an inactive gmail account to receive email. Why texts?
Well, we can't just trust your phone that its plan is valid, so there is also a service frame where the tower says "Sorry 12345/ABCDE, your plan is inactive!" that uses the same frame... and it has a 160-character frame for SMS too.
SMS is literally free for providers to implement, it is just an inherent part of the phone's ping/pong process of talking to towers. So there is certainly no requirement for an active plan of any kind. As long as your phone is on the network it is notionally capable of sending or receiving an SMS, the provider just won't let it... but usually service messages ("your plan is inactive, go to this website to top up!") will be allowed.
This is on top of emergency service - 911 calls (or local equivalents) will work regardless of plan status. Actually I'm not even sure you need a SIM card at all, or if that can be done simply by IMEI...
Basically: just because a sim doesn't have an active plan, doesn't mean the SIM or the phone isn't active itself. There is still information interchange happening, and that carries SMS frames.
The account is still active (say, for six months since your last payment) and there will be even more time before the phone number is recycled.
It's like the OSI model, there are multiple layers here representing different things. An IMEI is a representation of piece of equipment. A SIM is a representation of a subscriber (or, to be more precise, it's a cryptographic 2fa token that a subscriber carries), so a piece of equipment may have multiple SIMs and a subscriber may have multiple SIMs each associated with at most 1 piece of equipment (at a time). A SIM may be associated with a phone number, and may be associated with a plan which may be active or inactive.
The data model is really:
user <-one to many-> SIM token <-many to one-> IMEI
And a phone number is an at-most-one feature of a particular SIM token.
The fact that you didn't pay your bill this month doesn't mean your phone number is inactive - someone who dials that will get a "call cannot be connected" message because the phone network still knows it's you. The carrier just chooses not to connect your call, the phone number is still actually mapped underneath.
And even if your number eventually gets reallocated, the fact that your SIM doesn't have a number associated with it is irrelevant - the network still knows you by your SIM and knows your phone by its IMEI.
The phone number is really like a domain - it's a human-readable abstraction for the physical reality of the routing layer (SIM/IMEI). And the SIM is a representation of what user-token (a user may have many tokens, but a token has at most 1 user) is using a particular IMEI.
At the network level, they don't care about your phone number - that's just used for a "DNS lookup" of what equipment needs to ring. And they can send a message to that equipment even if there's no actual phone number associated with it. You can also have a IOT SIM where there is no actual 9-digit phone number to ring it (although that's a US-specific routing scheme, other countries do it different) and the network just talks to it via its SIM.
And even if you don't have a SIM (subscriber-token) the phone still talks to the network, and can still make e-911 calls and similar, you can initiate outbound traffic too, because your phone is still connected to the network even if there's not only no phone number, no plan, but even without a SIM. It's still an IMEI in a cell talking to some particular tower even if there's not a SIM in it, and can both send/receive metadata traffic or even real traffic (e-911 calls).
I'm probably getting the finer details wrong here too... it's a very complex model with a lot of entities and relationships.
For some fun tangential stuff on the topic, especially surrounding the SIM card, check out this DEFCON video. It goes into the 2fa nature of the SIM - actually the SIM is a full security processor (javacard) that can execute arbitrary javacard applets sent by the network, and push/poke stuff into the SOC or baseband directly, it is like an "Intel management engine for phones" and it has a huge amount of power over what the SOC can do and see on the network.
Of course it's the user's responsibility to actually keep backup codes somewhere where they can definitely be accessed in case the phone is lost and also can't be stolen easily. Ditto for a app backup. Sounds straightforward, but easier said than done.
Entertaining related story... a few months ago, I tried signing up for Celsius, the crypto exchange that went bankrupt. Their sign up process required MFA, and for some reason the only app they supported was Authy. Unlike most any other site, instead of giving you a QR Code to scan, Celsius would do something weird where they have some sort of push message mechanism that's supposed to initiate the MFA setup process from within the Authy app. I never did get it to work. I have a personal rule that if the signup/signin process for a service is too arduous, I simply won't use that service if I have viable alternatives. So I didn't lose any crypto in the Celsius bankruptcy because their MFA signup processes sucked.
Also you can use biometrics in Authy, fwiw. Then write down the password and put it in a safe. Then there's only 1 to remember but you can use biometrics in 1password too, so unless your threat model includes someone using your freshly chopped thumb then it should be ok.
TOTP has some limitations which make it not as secure as the better hardware-based approaches. For example if you get fooled into trying to login to a phishing site and the real site uses TOPT, all the phishing site has to do as ask you for the TOTP code. TOTP in this case only protects you from getting phished if the phishing site is just logging credentials for use later use. If they are going to use your credential right away it is no protection.
If a site allows both TOTP and a hardware-based system though you can use the hardware-based system normally, and only resort to TOTP if the hardware is lost or broken, and stop using TOTP as soon as you can get replacement hardware enrolled.
For TOTP when you are setting up and the site gives you the QR code, scan that in TOTP apps on your phone and if you have one on your tablet. Also save a copy of the QR code somewhere safe. I save an encrypted copy on my desktop computer. If you ever change phones or tablets, you can scan the QR code again.
Some sites will also give you the TOTP key in text form. Save that somewhere safe and you can use it with command line TOTP tools such as oathtool [1].
This is exactly what we did for PyPI: we allow the user to enroll as many 2FA factors as they'd like, of both supported types (TOTP and WebAuthn).
The post is dated 2019, but the summary of practices we wrote here[1] is still relevant (and IMO, correct).
[1]: https://blog.trailofbits.com/2019/06/20/getting-2fa-right-in...
Most 2FA apps have a convenient "move all of my codes to another device" function, offer online sync, whatever.
And even if they didn't, every service provides recovery codes that you could use in case of an emergency, should you need access to some service and all else fails.
Any cross-platform recommendations for TOTP program that works on Windows, Linux, Mac?
When presented with a TOTP secret, every website I've seen has presented the option to show the TOTP secret as text, which can be copied across.
A password database like KeepassXC can store the TOTPs.
FIDO / U2F hardware like Yubikeys (or various alternatives) are also a convenient second factor.
When I transfer phones, all that stuff comes with me.
For worst case scenarios, I have a few spare YubiKeys setup that I can use in the event that something goes haywire. And in a safe deposit box, I have a YubiKey and a printed out copy of my 1Password emergency kit. So that if someone drives into my house and it burns down, I do have an option.
But I agree that this is a lot of stuff to keep track of. That’s why I’m glad that Passkeys are being adopted by the big players (Apple, Microsoft, Google) and that we’ll see consumer rollout of this sort of thing, which should make this a lot better.
There’s no such thing as a system without a threat model — and biometrics can be imperfect, but I’m much more comfortable with that or even relying on my current MFA setup than I would be using SMS 2FA or no 2FA!
I've only gotten a new phone once. Was android to android. I was able to transfer everything from the old phone to the new phone as part of setup process
Granted, yesterday I had some trouble: my phone service failed to process a payment, so they disabled my service. Meanwhile I couldn't go in & review my bank info because I needed 2FA in order to login.. To make matters worse, the bank told me I needed to call a number for Loss Prevention Services to reenable sending money out of my account, & made me run around a bit looking for pay phones (surprise, they were out of order) before they let me use their phone
In my experience, ”rarely“ is more accurate than ”usually“.
I got worried when I started thinking about this scenario, and realized Google Authenticator offers no way to back up the tokens. The only way out is to transfer to a new device using a QR code. They pretty much lock you in to using Google Authenticator.
And, crucially, backing up the phone DOESN'T SAVE THE TOKENS.
I almost learned this the hard way when I got a new phone, restored from backup, and right before I wiped my old phone I decided on a lark to check that Google Authenticator was working on the new one. The app was there, but the tokens were not.
1. You get given recovery codes when you enable MFA. Each is a single-use code that stands in for an OTP code. If you kept them, you can use these to login and then change your device.
2. If you lost those too, there's a manual reset process. As you can imagine it's slow and requires careful scrutiny to guard against social engineering attacks on the rubygems.org maintainers.
In future it will be possible to use WebAuthn[0] for rubygems.org and, ideally, you will be able to bind multiple hardware tokens or biometric devices to your account, so that you have backup options.
Also realize you can use more than one 2fa device. At the step where it asks you to scan a QR code, you can scan it on multiple devices.
Also, you don't need to use a phone to store your codes. 1password can do this for you, and then your codes are available anywhere you are logged into 1pw.
The google authenticator app allows you to transfer your codes to another phone, but you need to remember to do that before wiping your old phone.
The services themselves (rubygems etc.) also provide a short list of one-time account recovery codes. You’re supposed to essentially print them and put them in a safe. I wonder how many people both keep those codes and keep them somewhere secure…
1Password offers MFA and would still be available on your other devices if you lost your phone. As to if storing passwords with MFA codes is fine or a problem, I’ll let smarter people than me decided what’s best practice.
I had a similar question and wrote up how I'm doing it here:
https://earthly.dev/blog/multi-factor-auth
Oathtool:
Other 2FA apps have backup options like Google Authenticator or Microsoft Authenticator. Bitwarden, if you pay for premium, gives 2FA as a feature and they just handle those codes. Just don't register Bitwarden 2FA under itself :D
If you have 50 two-factor authentication tokens you can use apps like Authy that allows you to do a local or remote back up of the tokens. TOTP is an RFC standard and you will find lots of apps for advanced users.
You can backup it to other phone or even print it and lock it somewhere if you want.
Backup code (very long, one-time-use password.)
Well RubyGems itself, subject of this post, has 12 for a start.
GitHub's codes are 8 alphanumerics,
Dropbox 8 alphanumerics,
Live.com offers a 25 alphanumerics
Google 8 numeric
Facebook 8 numeric
Nintendo 8 numeric
Login.gov 12 alphanumerics
Gitlab 16 hexadecimal
I'm sure some fool somewhere used a six digit numeric "recovery code" but the usual, while it isn't 40 is certainly more than 6.