Yeah, and it requires me to use a U2F token, which I can loose, etc. You have to balance security and usability, and SMS as a second factor seems like a perfectly reasonable balance.
I witnessed so many people lose access to their accounts because they wiped their phone that had an authenticator app, or they lost their physical 2FA tool.
But it is a whole lot of extra work to set up and maintain long-term, even with the best intentions.
For personal use it probably is a good compromise for services which don't implement 2FA properly (that is to say, services that don't allow you to register multiple 2FA devices.) But realistically you might want to just disable 2FA and rely on your password manager.
I'm not sure what you meant by this, Authy certainly provides TOTP, and the encryption password is only used when you need to sync the 2FA secret to other devices, which by the way also requires confirmation using SMS to your phone number as well.
It does seem like this is somewhat more secure, in some sense, but it weakens the security that TOTP is intended to provide.
In any case I don't see how the Authy password can weaken TOTP. It's not like there's a webpage out there where you can enter the Authy password and it will give you back the TOTP secret for a specific user. It's only used to decrypt the TOTP secret if you choose to sync that secret to another new device, which again requires SMS verification, PLUS confirmation from an existing device, PLUS you need to have the sync capability setting enabled (so you can always sync the TOTP to your backup device first then disable the sync setting to prevent additional devices being synced).
I'm annoyed Google Authenticator makes it so easy to transfer accounts to a new phone, how will you know if someone's cloned your TOTP private key while you were sleeping?
This is really great advice.
I do something similar. I have a copy of the recovery codes (where possible) in an encrypted volume with multiple copies. Also printouts. The printouts have saved me once already.
Also, don't underestimate the utility of carrying around an encrypted SD card with things you want to retain access to!
1Password in particular encrypts your vault with your master password and importantly an additional 128 bit secret key that is meant to be kept somewhere physically (e.g. in your safe). This key is needed the first time your vault is decrypted (e.g. a new device)
An attacker would need to have access to all of the following:
a) your encrypted vault
b) your master password
c) an 128-bit secret key
in order for the fears you've outlaid to be realised.
Really the only attack vector I can see is a physically compromised device (brute forcing is out of the question). In which case, they'd still need to somehow know your Master password and you're no more vulnerable considering your OTP is likely to be in an application on your phone anyway.
Using the 2nd factor on another device as the first means attackers need to either compromise 2 devices, or compromise a single point higher up in the hierarchy (e.g., your google account).
If there’s malware on your PC that has complete access to your system memory you are screwed in every single way possible. I’m perfectly comfortable with having my OTP coupled with my passwords given this is the only real attack vector and requires an actively unlocked vault to expose secrets.
If this is the case, what’s stopping the malware from adding a key logger and MITMing your input to your bank’s website, Gmail or Coinbase?
1. You increase the risk of losing your entire life (if 2FA is properly implemented and avoids all social engineering process risks)
or
2. The 2nd factor devolves into a 2nd way to get access to your account
You really can't have both security and convenience.
> wiped their phone that had an authenticator app
try this one: battery dies in an iPhone. iPhone won't boot until battery is replaced. Battery can only be replaced at an Apple store. 2FA: do you feel lucky, punk?
Proper support would mean allowing multiple tokens, so that you can have one permanently on your keychain, one permanently in your computer at home, and an off site backup pair that you rotate (enroll the one that is at home, then swap and enroll the other one).
On desktop, touching a U2F token is a lot easier than typing numbers from a SMS, and it actually protects against one of the biggest threats, phishing (the SMS does not - if the phisher bothers to ask for it, the user, who thinks that they're logging into the legit web site, will enter it).
Best compromise between usability, access and recovery is to always use TOTP but be sure to always securely back up the secret offline. Don't ever just scan it into a single device, as then you're back to being able to lose it and be locked out.
IMO both the mobile provider and the web site operator should be jointly liable for damages resulting from SMS 2FA abuse. The mobile operator for giving access to your phone number to an unauthorized person, the web site operator for using a known insecure technique.
Both the number of successful hijackings and companies using SMS 2FA would drop drastically.
Besides, I don't believe coinbase does SMS only account recovery. So here SMS really did fail as a second factor. Since it seems attackers must have had a password and SMS. (I am not 100% on the coinbase account recovery process)
So the hacker only needed to hijack his SMS.... with that, they gained access to his email, and then with that gained access to coinbase. No password required.
How many services do that today? And since so few people have fallbacks what is their recovery process like? Because the hackers will find the weaknesses.
AWS is the counter-example which will be (indeed already has been in this HN comment tree) cited as proof sites don't all do this, I've tried asking if there are literally any others, and never received any ideas. I don't currently have an employer and I don't use AWS for personal projects.
It's pretty common for sites that actually care about authenticating you (so, Google but not your Bank, GitHub but not your mortgage lender) to provide you with single use bypass codes which they tell you to write down and keep somewhere safe.
Put a plan together for the "house burns down" scenario.
With U2F I need to enroll multiple tokens and keep some off-site. So what does this entail? I keep maybe 3 tokens, two on-site that I add the new account to, then on a regular schedule I rotate one off-site and bring the third one on-site and go back through and add it to any accounts I've created in the meantime? The whole process is a pain in the ass, and not all sites allow multiple devices to be registered (e.g., AWS). And new accounts are still vulnerable during the time between registering and rotating the third key on-site.
With TOTP you can... just sync your TOTP database. Some apps such as Microsoft Authenticator do this on their own. Personally, I put all my TOTP secrets into a Keepass database and sync it off-site with Nextcloud. There is no way for the site to limit how many devices I enroll so it's easy enough to create as many backup devices as you need. If you're really old school, you can print the secrets and put them in a fire safe.
FWIW, I have several yubikeys. I primarily use them as a secure store for TOTP secrets and to store a SSH key (generated off-device and backed up), not for webauthn. It's just too annoying to deal with in a way that ensures I don't lock myself out of an account.
Every modern TOTP app is cloud-synced, so I'm not sure why people are saying it's "a pain in the ass if you lose your device."
Heck, most modern password managers (e.g. 1Password, LastPass, etc.) are also TOTP, and help you fill the TOTP token (usually by putting in on your clipboard) at the same time they autofill the password.
> It is also weak to phishing (extremely common) but adds protection against SIM-swapping (comparatively very rare).
Sufficient paranoia / user training is enough to protect against phishing. (Especially for services where the only "users" are the extremely-paranoid IT admins themselves.) But nothing can really protect you from SIM-swapping, save for not allowing services that use single-factor SMS recovery to ever know your phone number in the first place.
I've got a few services that only support Symantec VIP, which does not allow you to extract secrets.
> Sufficient paranoia / user training is enough to protect against phishing.
Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.
See https://www.reddit.com/r/1Password/comments/8yey6y/how_do_i_...
(PITA, I know, but running little auth gateways like this is part-and-parcel of doing security for an org.)
> Considering how easily actual factual professional security engineers fall for phishing, I don't believe you.
It's almost always the service's fault for being designed in such a way that its real async user interactions are indistinguishable from phishing. You can't train a user to distinguish X from X.
• It's hard to train users to not forward TOTP tokens sent to them to someone else, if the real service will text or push-notifies the user their TOTP token "at random" (i.e. because the attacker tried to log in.) But if the service never does that — if you always have to go and fetch the token from your TOTP app — then you can just tell the user that the only time they are to go do that, is right after they've typed their username and password as part of logging in themselves; and that anything else is a phishing attempt.
• It's hard to train users to not type their username+password into phishing login pages, if the services you use constantly send you emails containing deep links. But if the service never does that — if the service always tells you to go your browser and navigate to the site yourself — then it's easy to teach users to never trust a login initiated through an email.
Security, in this case, is less about "good security hygiene", and more about priming/expectations. And because of that, the practice of being an IT admin for such an org, is a practice of picking services, or negotiating with services, to ensure that the service is following secure workflows when dealing with your users, so that your users can be trained.
> It's hard to train users to not forward TOTP tokens sent to them to someone else, if the real service will text or push-notifies the user their TOTP token "at random" (i.e. because the attacker tried to log in.) But if the service never does that — if you always have to go and fetch the token from your TOTP app — then you can just tell the user that the only time they are to go do that, is right after they've typed their username and password as part of logging in themselves; and that anything else is a phishing attempt.
A phishing attempt will do precisely this. You get a fake login page, type in your creds, and then you get a fake TOTP page.
> It's hard to train users to not type their username+password into phishing login pages, if the services you use constantly send you emails containing deep links. But if the service never does that — if the service always tells you to go your browser and navigate to the site yourself — then it's easy to teach users to never trust a login initiated through an email.
In a prior life I did some research on phishing. It is embarrassingly easy to fool even professional security researchers. Nobody is capable of consistently preventing phishing by using their own eyes and brain.
While TOTP contains a bypass (phishing) SMS contains an additional vulnerability.
(Unless you use a solution like Authy with multiple devices, which strikes me as the most sensible solution.)
All of that made me switch to Microsoft Authenticator, as they do have both multi-device sync and "recover from backup" feature as well, so now I don't need to be stressed about my phone getting lost. Kind of sad, given that I've been a user of Google Authenticator for quite many years until that point.
This is more portable than U2F tokens since client-side certificates are part of the TLS standard and should be supported regardless of the application protocol used. Adding other devices could be done by sending a CSR along with the username and password and authorizing the second device from first device that's already logged into the account.
But Mozilla, and Google double teamed to sink it in W3C to push their own bicycle reinvention attempts, which after 10+ years, multiple incompatible versions, and errata ridden revisions are still not there.
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0001.ht...
Google needs to be kicked out of W3C
In which case there are much safer recovery mechanisms available. For example, a second U2F token, or handwritten backup codes.
> and SMS as a second factor seems like a perfectly reasonable balance.
My point is that it isn't. Unfortunately, today, identity is a true privilege - it pretty much requires purchasing multiple U2F tokens, and that's super shitty. That doesn't mean that SMS 2FA is a good idea - the fact that it can actually reduce your security is very problematic.
The only way it can ever actively reduce your security is if it's used as a single factor, as it was for the OP.
I don't believe this is true. If I have your SMS I am considerably more likely to be able to phish a recovery, even if recovery also involves something else. Every piece of information the attacker can get is valuable for forging auth.
What SMS is good at is being available. At this point cell phones are distributed to a massive portion of the world. But at this point smartphones can also act as U2F devices, I believe, so I'm not sure that benefit is so meaningful anymore.
Instead of companies wasting time on SMS 2FA they should be figuring out how to help their customers set up U2F.
I'd like to avoid being in a situation in 10 years where we have great options for end users available but 2FA SMS is still supported for legacy reasons, and unwitting users end up using it because it seems easier and they don't understand the risks.
So it's better to not consider that information at all?
What is better? (1) Requiring a password to login or (2) Requiring a password and a code sent via SMS?
The problem you're describing is that services accept SMS in leu of other forms of verification, such as an actual password. Personally, I would very much like it if I could turn off any and all forms of "I forgot my password" flows. There should at minimum be a one-week waiting period or similar.
Exactly
> What is better? (1) Requiring a password to login or (2) Requiring a password and a code sent via SMS?
They're equivalent in my mind - SMS is such a weak 2FA mechanism, and it's so easy to get wrong and have it decrease your overall security, any benefit is lost. Rather than pushing SMS because it's what we have we should make greater efforts to leverage technology that we know is considerably better in every regard except availability today - IMO that is the problem to solve.
Which have either higher costs or "administrative burden" or both which will lead them to failure for a big chunk of non tech-savvy people. Educating a casual user that they need to print out recovery codes and store them in a safe place it's not exactly top notch usability.
So then have two U2F tokens. Or use your phone's TPM as a U2F token. The usability of phone-based U2F is quite good.
IMO the problem is not "let's get some kind of 2FA" it's "let's get U2F in the hands of as many people as we can".
There is pretty much no form of second factor that users are worse at passing than backup codes. Even if people print them out (few do), they won't find them when the emergency happens. You need some form of trust that can be bootstrapped again from scratch.
For most of the world, SMS is it. The Nordic countries have the bank if system. But the market is too small. Hopefully the EU-wide identity verification systems solve the scale problem.
I responded to this in another post.
> There is pretty much no form of second factor that users are worse at passing than backup codes.
Agreed, I also mentioned backup U2F. At this point modern smart phones package TPMs that can also do attestation, so we're really not too far away from being in a situation where the vast majority of people have a U2F token in their pocket.
This is not using it as a second factor. It is using it as the only factor. Having SMS as the only factor is not purely additive. As such it can (and obviously does) reduce security.
Account recovery is hard, SMS is quite usable there, but way to insecure to be the only basis for bootstrapping account recovery.
Let's say that you remember your password, but your house just burned down. You cannot replace the U2F keys and backup codes that were lost in flames. But you almost certainly can bootstrap your real life identity far enough to get a replacement SIM.
Which, in combination with your password, should be enough to get your digital identity back.
But indeed, sms as a second factor is much easier to recover in catastrophic situations than some other second factors. That is a fair point, and an advantage of sms over other common second factors.
SMS is perfectly fine as a second factor, and terrible if it can serve as the only one factor.
You are forgetting social engineering. Humans find it reassuring that the security process happened as usual, even if in fact the apparently "usual" process was them being being phished. This can mean they're actually less alert than they would be otherwise.
You get an urgent message from your bank about an unexpected $500 transaction, you follow the link & you need to enter your password as usual of course, and then it tells you that you'll get an SMS and to type in the code so you do so. Phew! Disaster averted! Right? This must have been real, you even got an SMS from the bank.
Alas the SMS was from your bank, and the bad guys didn't have a way to intercept it, but they didn't need one because you typed it into their phishing website. That unexpected $500 transaction wasn't real, but their emptying of your bank account will be.
"You get an urgent message from your bank about an unexpected $500 transaction, you follow the link & you need to enter your password as usual of course. It was a phishing website. Your bank account will be emptied."
It did not reduce security.
It most certainly can reduce security, that's the point. If I don't have a phone number on my account (which I almost universally don't) then no amount of SMS hijacking will ever matter.
If some provider forces me to put a phone number in, now I may be vulnerable to a weakness I didn't want to be vulnerable to. Maaybe today that particular provider uses SMS in a stricly additive sense. Maybe. Just as likely next month they'll redesign their site to be "easier" and add back the vulnerability.
Same with recovery questions. They make the security stricly worse for most people since they are password-equivalents with far lower entropy. Although personally my best friend from high school was named D3ho9WvylJkws1zfAKUxZjdYuCsS.