Tell HN: SMS-based two-factor authentication is not secure
I am with Boost Mobile. On Sunday night I received a text message that my PIN was changed. Within minutes I confirmed this to be true on my PC. I used the Boost application on my phone to change the PIN and received a confirmation text.
A few minute later I received a text message welcoming me to Metro PCS.
A few minute later I received emails to my business email that my account security information was deleted from my person email account. They used SMS authentication to my mobile number, that they now have control of to gain access.
A few minutes later I received an email there was an account recovery attempt on my coinbase.com account.
It took less than 30 minutes for these events to transpire.
I've spent about 15 hours trying to get my phone number and my email address back to my control.
I've accumulated a list of eight other people in the Boost Mobile Reddit.com forum where the exact same thing happened to them.
I filed a police report and filed a report with the FCC. I received a response from the FCC that they have started the inquiry and contacted Boost.
I finally did get my cell phone number ported back to Boost. I have not gained control of my Microsoft email address.
I didn’t realize I could only have messages of 2,000 characters. So I will wrap this up.
When account settings were changed, Coinbase gave me a link to lock my account, Microsoft gave me a link to log in to my account, which I no longer have control of.
Unlike competitors, which allow pins from 6 to 15 characters and for accounts to be administrative locked, Boost offers none of these options. The last Boost operator suggested I pick a more secure PIN.
I am calculating my losses and documenting all interactions.
289 comments
[ 3.0 ms ] story [ 165 ms ] threadThe very things that make SMS a uniquely good second factor make it an awful only factor. Use of SMS for account recovery should in general (or at least for important accounts) have a delay (order of days) that allows the real user to intervene.
Where it's used as a second factor, this still has an impact which is, if an attacker can get the password (and there's been enough breaches and keystroke logging for that to be common) they can then grab the number to get full control of the account.
TOTP or hardware tokens don't generally suffer from the same problem.
If you see it as "don't bother, they can just steal your SMS number" instead of "that's slightly better, at least now they can't get in without stealing my number" then you're not thinking about this reasonably.
It's inane to neglect to use SMS where it's the only second factor available. The exception is when a service allows you to use SMS alone for password resets, which isn't MFA, is 1FA with a weaker factor than a password.
What would you think if someone took you for a joyride in a classic car and said "shoulder belts would be so much better than these lap-only belts, so don't bother buckling up!"
SMS 2FA was vaguely reasonable before TOTP applications and smartphones capable of running them were widely available. That's no longer the case.
With some applications, you can add additional devices, so you can add multiple, if you have 'em.
I enabled TOTP on every account I have that supports it, which comes to about 2 out of every 5 services. I'm not going to leave the other 60% with only one factor just because SMS can be exploited, which the consensus in this thread seems to be advising everyone to do.
Asking before you sign up, "will you allow my account to be hacked through social engineering?" isn't going to an answer other than no. Even if the answer is possibly yes.
You can check if they appear to allow it today. Not perfectly, as they may have multiple variants and depending on other factors you might get presented with one or the other.
But you have no way to predict if next month a PM there decides their current password reset was too cumbersome and they change it to SMS-only. If you had a phone# on file, you're now suddenly vulnerable.
For those reasons, even as a second factor it's a terrible one. SMS is just not a good method of authentication at all and has no place in a login form.
At it's best, SMS is only useful as a read-only notification system for non-sensitive purpose.
2. It pops up a username/password screen. The user types in their credentials for realbank.com.
3a. The owners of fakebank.com use your creds to log in to realbank.com and are presented with a TOTP page.
3b. fakebank.com loads another page that asks the user for their TOTP. The user enters it, still thinking they are logging in to realbank.com
4. The owners of fakebank.com use the TOTP to authenticate as the user with realbank.com.
Entire SDKs to automate this are sold on the black market.
The point is the TOTP is precisely as bad as SMS for the common case (phishing) and only safer in a rare case (SIM-swap). This comes with large downsides (losing access).
TOTP is, at best, a very marginal improvement over SMS. This is what makes the online push to complain about services that use SMS 2FA and demand a switch to TOTP very strange.
You're sure this is the right web site. But Bitwarden won't fill out the code. What could be wrong? Did the idiots who make this web site change the URL?
Now, maybe you're a far above average user and you would calmly determine the exact cause, assuming at every step that the most likely explanation is you're being phished. Hopefully that's more likely now that you've done this exercise. I would love to believe I'm in this category.
But most users will just be frustrated, why wasn't it filled out? Is there a way to get the code from Bitwarden anyway? There is, it's a bit fiddly but you can do it. Lots of users are going to do that. They might even help each other to give their credentials to bad guys, community spirit.
Hopefully some of those users pause because this is unusual and a few of them will realise in that moment that they're being phished. But experiments suggest most won't.
Maybe the Bitwarden extension should warn users when they try to copy/view a TOTP code by searching for a login rather than using a matched entry.
U2F is my preferred method of MFA, but many services don't support it, and there can be practical issues even for the ones that do. For example, some services support U2F in a browser but not in mobile apps.
you can phish SMS exactly the same way you can phish TOTP, I'd say :)
It also comes with large downsides. Security is an economics game. Marginal improvements in security posture are not always worth the cost.
There are a bunch of people who insist that web services should drop SMS completely and demand that all users use TOTP (at least). I question the value of this change given that TOTP only protects you in comparatively rare cases.
But how many hardware tokens or TOTP tokens are users willing to deal with? I currently have eight for various clients and systems at work. If each online account required a TOTP token or a custom hardware token it would be a confusing mess of tokens.
I don't know if there's a safe and easy way of reusing the same token across sites. Until then SMS really is the only "solution".
Usually you get a UI where you can add new ones and remove old ones, and when you add a new one you name it in their UI so that you can tell it apart from any others.
If you only support one token but have an easy recovery procedure, that opens up loopholes. If you support multiple tokens, allow the user to de-activate one token from another token, and make recovery difficult, that's much more secure.
Dropbox, Facebook, Google, GitHub, GitLab, even Login.gov works fine with multiple tokens.
More sites should do WebAuthn (you should not do greenfield deployments of U2F today, WebAuthn is the standard). Yes, AWS should fix their feature but that shouldn't block the next ten would-be Unicorns from doing WebAuthn.
Point is whether it's U2F or Web'n'Auth or TOTP they need to support multiple keys.
https://support.kraken.com/hc/en-us/articles/360001363963-Yu...
It doesn't make sense to try to "support multiple keys" for TOTP. You can copy-paste TOTP seeds if that's what you want and feel comfortable with, if the site tries to allow you to use any of N seeds they not only increase their system complexity they also reduce their security by a factor of N which makes no sense.
Edited to add: OK, Coinbase does now have U2F and they clearly state you can use "a maximum of 5 keys" which feels like that's enough.
Even in a situation where the attacker would have needed the password too, consider how much more vulnerable you are now that they have a significant piece of your auth - could they leverage that to social engineer an account recovery?
Phone numbers are terrible at conveying identity, unfortunately, so bringing them into the "who are you" heuristic is kinda just a net loss.
Not only that, but you can remove the username too: WebAuthn supports a "usernameless" mode where you press "login", touch your authenticator and you're in.
I'm very much looking forward to password managers acting as soft-WebAuthn tokens so they can hold a simple private key and log you in to sites automatically by answering the login request. That way, you only need to unlock your password manager and you can log in to any site without a u/p.
Just don't get your password manager stolen, I guess, but that's already the case.
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.
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.
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.
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.
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.
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?
(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
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.
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).
It is possible that if we spent more time as a community encouraging the use of password managers that the net improvement in security posture would be greater, but this does remain a nontrivial benefit of SMS.
U2F is only an authentication tool, not security/encryption one.
If you have your smartphone/browser/pc pwned, you are even more screwed than with offline key table/token.
For something truly security critical, you need security against MITM on your own device, which only leaves smartcards as an option.
U2F and 2FA came to life just because people are bad at making passwords and remembering them.
Making non technical people to use password manager with generating passwords for each page is still hard.
Making non technical people use SMS as a second factor is easy.
Making non technical people use tokens is still hard.
There is a lot of value in having SMS 2FA still, yes you can phish it or you can hijack the number. But that is argument like: "there is no point in having any security at all because if you install malware on your computer you will get hacked".
Yes SMS alone is not going to save you, but people have phones and understand that they type code that comes via SMS to the phone number they provided when registering. Barrier to entry for it is so trivial that I think it still has value.
Barrier to entry to take over someones phone is not high but random kid on the street is not going to do that just like random kid that can find your email + de-hashed password from database dumps.
If you have someone who is motivated to get you then probably given enough time they will get you anyway.
So take into account what that SMS 2FA prevents and what issues it is solving. Don't just throw it away.
It might be confusing but that was account recovery attack.
For account recovery there is no "password" as thieves just made their own password while having victim phone number.
So phone number as a password recovery option is not secure without any additional checks. Not 2FA because with this attack there was no second factor.
No, SMS shouldn't be a single factor, period. It doesn't prove much, and is insecure, as the current post shows.
Now is SMS the best second factor? Of course not and a proper U2F token will be a lot more secure in many cases but for most people SMS should be perfectly suitable. All this of course requires the auth provider to be somewhat competent and not use SMS as an only factor in any circumstances.
One option I’ve heard might be different is to not your your mobile sms on accounts, but to get a voip based sms number. It might leave things at the mercy of a different system but the footprint might be different.
I hate it that Twitter forces you to enter a mobile phone number even when you set up an authenticator code generator as 2FA.
Oftentimes the weakest link in most of these services is the account recovery part.
When we set up the self service account recovery in saas pass password manager and authenticator we added all of these customizable options to mitigate against potential SIM Swap attacks.
https://blog.saaspass.com/saaspass-password-manager-authenti...
To move my phone number (consent or not) between any phone companies requires an SMS, my National ID, and verification of my ID, and personal details in the government database.
SMS by itself is not secure.
[1] https://www.gov.il/he/departments/news/sim
The one thing I distinctly remember was two of my GMail accounts starting the recovery process. Thankfully, that process apparently gives either 14 or 30 days to stop the recovery and secure my own account. Had I not been connected, that may have been my only saving grace, as I was able to secure those accounts and subsequently use them to recover other compromised accounts.
The larger lesson for me was to always use TOTP tokens where possible over SMS, and to completely disable SMS recovery for accounts that didn't have a delay on SMS-only recovery.
I deprecated SMS 10 years ago and the only way I receive SMS codes is via an online interface that is password access.
For most people, SMS fails miserably when you need to change your SIM card or fly to another country, or work out of a place with no cell reception but has wired or wi-fi internet access. That's a big part of the reason why I deprecated it in favor of e-mail, which works flawlessly anywhere in the world you have an internet connection.
I only support U2F or TOTP based 2FA and it's upto providers to get with the beat if they want me to use real 2FA.
It's a little mind boggling though. Securing money with a $15/mo phone plan. It's an extremely ghetto phone service. If anyone's to blame, it's Boost Mobile. Cricket Wireless. Pay for a major carrier plan.
[0] https://news.ycombinator.com/item?id=27311641
Boost mobile is negligent and not following industry standards. Their whole security model is based on a 4-digit pin. At first I thought somebody had a script working its way up through all the combinations at the login screen, but I no longer feel that is the case. The fact that at least nine of us had this same issue within days makes me think there is a wide-spread issue here.
It might be confusing but that was account recovery attack.
For account recovery there is no "password" as thieves just made their own password while having your phone number.
So phone number as a password recovery option is not secure without any additional checks. Not 2FA because with this attack there was no second factor.
I agree that SMS 2FA is not secure and a terrible idea. I've moved countries and my old mobile number has been given out to someone else. I don't even know what accounts I have might be tied to that phone number and I don't have any way to find out.
I have had friends message that person without knowing it as well. He could easily impersonate me on WhatsApp and fish for my personal info from those contacts.
Luckily, he seems to be a decent person but I not only have to trust this stranger to be honest, but also need to trust that the number stops at him or goes to another honest person if he drops it.
Phone numbers are not identity and using it for verifications of this sort is a horrible idea.
Experts know this (because it's obvious) but large companies like Google continue to insist on using it either because they like the data collection or because they're just covering their asses.
If I'm giving advice to companies, I say "don't use SMS 2FA as 1FA" (well, I actually say "don't use SMS 2FA at all, it's too tempting for a support person to use it as 1FA"), but this thread is about the user, and as a user, you shouldn't use SMS 2FA.
So you are not against phone based 2fa or 1fa, your are against giving companies your phone number. But them, if they are soooo careless to try phone based 1fa when they can get away with it, they are also probably open to some social engineering.
In the words of RMS: "We should all try to make those companies fail."
(OP, you are calculating your losses, but didn't specify what those losses were. Did the theif get your crypto?)
My account is locked, and I am pretty sure my funds are still there. It will be a significant loss, but not devastating as this was my non-primary investment account.
I still don’t know the full extent of my losses.
So far, my losses are primarily loss of billable time. I am not a litigious person, but I am also going to educate myself as to what ‘pain-and-suffering’ means. Both my personal and business bank accounts are ok. I now understand why banks do not use email addresses as the login id. The thief would not (easily) be able to align my email address with my bank login id.
Once through this, I plan disassociate any portion of my login id with my name.
You haven't even tried to regain access to it? Instead of spending time on HN you might want to reach out to Coinbase.
This is an important point and one I've been thinking about for years. There's so much discussion about using password managers and good password practices and 2fA but almost no discussion on how using a single identifier to log into all these various services is in itself a huge security vulnerability. If we had different login usernames for each service, gaining access to people's accounts would be that much more difficult.
Email should be reserved for communications and not double as a means for authentication.
What happens if a legitimate customer's phone gets lost and they quickly transfer the number and reset their accounts?
I think they should do a video call verification.
Video verification sounds reasonable, as would some wait time. What's not reasonable in that situation is a self-service fully automated account recovery via SMS and e-mail verification followed by allowing withdrawals.
I moved countries and I am now locked out of my bank account abroad since they verify logins via OTP over SMS.
But I feel your pain. It is very frustrating situation to be in.
I suggest a bank which doesn't suck, such as bunq.
Let's not blame the victim here.
I moved from Ireland to the US and kept my Irish number active - the cost was a €5 topup every 6 months.
Going in reverse is much harder - a lot of the budget phone providers in the US don't have any roaming offering. Best I can tell, you really need to have an account with a real provider, and that realistically looks like $20/mo (Google Fi), 20x more expensive than the reverse.
TransferWise doesn't require a US phone number, but you can have a US account number with them.
I sometimes wonder why Google has kept it running for so long, when they’re so keen to kill off boring, under-performing products.
Is it even possible to do this at this point? I'd expect something like this to fundamentally change the way telephone networks work.
But even if it is fundamental, such fundamental change is needed.
If regulators and the industry saw a future in figuring this out (as compared to dealing with another hassle from a unsexy legacy technology mostly used by old folks), it would have been solved a long time ago.
If they do require it, then I believe the consensus is that 2FA via SMS is a very bad choice. And since Google Authenticator (and other such apps) are free to download and use, it's not really a burden.
SMS is very bad as a 2FA, in that someone can fairly easily social-engineer your phone company to send them a new SIM card for your account, and once it's in their phone, all your SMS messages go to them. They now have control of your "protected" account (and yeah, they have to get your password as well, but if you're a big enough target, it's worth it).
This is why getting rid of SMS entirely as a 2FA is seen as an improvement in security.
Despite that, despite still having access to the email the account is on, I cannot recover the Microsoft account. Despite Microsoft notifying me that the account is still, years later to this day, being abused, cannot use any form of recovery. I cannot access the account with help from support or even after visiting a brick-and-mortar store.
It's one big reason that I've long since refused to purchase anything more from Microsoft and have ditched Windows.
Good luck recovering your stuff.
This happened to me. I was briefly a contractor at MSFT and was able to escalate the issue -- after a few years, these accounts get automatically deleted. It's likely that your account is completely wiped and no longer exists.
If that's the case then why do I get emails notifying me that unusual sign-in activity is occurring? And, why am I unable to create a new account with the same email?
Protonmail is the best beacause it does not require backup emmail or SMS, just the username and password and 2fa being optional (but you must have the password), which is how it should be. So many people have gotten hacked through phones and or recovery emails.
Payment is not done over SMS but separately through cash or Venmo, so it seems like the worst that could happen is a delivery gets nefariously ordered for someone who didn’t want it.
The threat model is increasing for personal use as solely SMS based account recovery is becoming more widespread. The increase in crypto usage is another accelerant.
Good luck solving this unfortunate incident.
The barrier is higher than random automated port scans but the value of being able to get access to financial accounts is high enough to justify the investment.
I use Authenticator apps wherever I can. Where I can’t, I use a completely private number for 2fa (I run a virtual number product that is like Google voice for Australians to do so http://www.benkophone.com)
I think it's a shame most banks (at least here in the UK) implemented 2 factor auth with sms only just to comply with "strong" auth regulations.
Authy on your phone or multiple u2f tokens are definitely better than SMS.
I wish computer manufacturers started including tokens with computers, so that at least people would start using them.
* SMS authentication is not the same thing as 2FA, but people think that it is.
* SMS account recovery is convenient for the bad guys.
* The fact you got a welcome text from Metro PCS. If that was sent to your Boost device, someone from TMobile (they operate the networks that both Boost and Metro ride on) needs to take a look as that should not have been able to happen.
* In order to port a number you have to know the account security question's answer. Boost does have this. Was this bypassed?
SMS 2FA is not for you.
They say it's for you (for your security or your protection or your ease of use or whatever) but that is a lie.
In cases where SMS 2FA is forced, to the exclusion of all other proofing mechanisms, it is generally because the provider has a brutally difficult spam/scam problem that is complicated to solve.
So, instead of solving their spam/scam problem, they just throw some sand in the gears (of their users) and very loosely attempt to piggyback on the physical phone / physical SIM / physical ID confluence that constitutes a "normal user".
This is, of course, a very leaky mapping and anyone determined can, of course, work right around this. But it does seem to lessen their (again, brutally difficult) spam/scam problem.
The most ironic deployment of this (desperate) technique is Twilio whose own numbers cannot be used for SMS 2FA auth[1] and yet they require a true, mobile (non-VOIP) number to use their own service.
[1] Twilio numbers are not mobile numbers. Most SMS 2FA is sent from "short codes" and short codes cannot SMS non-mobile ("voip") numbers.
The amount of 'splaining going on in this discussion helps illustrate the trouble. If SMS2FA were actually fit for purpose it would not require so many internet defenders.
[0] https://blog.cmpxchg8b.com/2020/07/you-dont-need-sms-2fa.htm...
It is a mistake to ask consumers to protect, backup, and secure their digital lives themselves. Consumers don't have the time or skills to keep up with the hackers. If Apple, Google, ATT, Verizon etc. cannot provide digital security, this is an opportunity for someone else to step in. My personal suggestion is this is a ripe opportunity for someone like the US Post Office or Department of Motor Vehicles. Consumers would go to the US Post Office or DMV and purchase a Yubi key from them. The additional value they add, is they can verify the identity of the consumers who is purchasing the Yubi key and replace the key if it is lost/stolen. Similar to how they process driver licenses or passports. This service is optional and would actually cost money. I would gladly pay a monthly fee for this peace of mind.
Pay some $ for the key, renew it every 2 years for a fee, pay for a replacement if needed.
No one wants another monthly fee, taxes should keep the infra up like any other license.
It's usable for almost all government agencies or official stuff online here, but I haven't seen anyone use it for third party auth as it costs roughly 10 cents per login for the service using it.
In Norway, Sparebank1 is pushing an app to get one-time codes now. I wonder if we'll see more of these in the future?
I use the Microsoft authenticator to get access to my Microsoft work account.
I bet if everyone starts making their own apps for one-time codes EU will demand a single app to do all of this.
This sounds like it might be a so-called “flash” SMS. https://en.wikipedia.org/wiki/SMS#Flash_SMS
It is 100% insecure, and been exploited for nearly a decade.
1. Anybody with access to raw SS7 network can basically click a finger, and have you traffic rerouted
2. GSM interception gear is widely available
The person who invented "SMS verification" was a round idiot
Uh... what does (in)secure mean to you?
If there is not a self-service recovery option for me losing my phone, I won't use it.
---
FWIW I keep a copy on my desktop and on my phone (Keepass) and sync them every few weeks. I try not to add new passwords to my phone copy in order to keep things simple, but Keepass can do diffs and merges.
"But if your safe is owned, then all your accounts are owned!" Yes, that's the balance I take. If someone is able to get my safe and use my bio auth on the phone OR otherwise crack it, I'm screwed.
> The additional value they add, is they can verify the identity of the consumers who is purchasing the Yubi key and replace the key if it is lost/stolen.
This is exactly how digital signatures work in my country. A government institution vouches for digital certificate companies which verify and certify people's identities. It can be used to file taxes and lawsuits, for example. To most people this is just yet another layer of bureaucracy.
It was a bit complex, but I eventually got Keepass to generate the TOTP codes which so far are pretty awesome.