[HN Gopher] Tell HN: SMS-based two-factor authentication is not ...
___________________________________________________________________
Tell HN: SMS-based two-factor authentication is not secure
SMS-based Two-Factor Authentication is not Secure. I've read this
before but brushed it off. It wouldn't happen to me. It did. 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.
Author : Zolt
Score : 485 points
Date : 2021-06-09 12:40 UTC (10 hours ago)
| LinAGKar wrote:
| Too bad there are those that still only allow SMS, e.g. Sony.
| Patreon used to be the same.
| headmelted wrote:
| Sony allows TOTP.
| max_ wrote:
| TOTP is the best.
|
| The problem is how to effectively store the secrets for recovery.
| meowster wrote:
| I think crypto companies should block withdraws for a period of
| time after a password recovery.
|
| (OP, you are calculating your losses, but didn't specify what
| those losses were. Did the theif get your crypto?)
| ccn0p wrote:
| i thought coinbase did just this.... either made recoveries a
| multi-day thing, or disallowed transfers afterwards. maybe that
| was blockfi.
| Zolt wrote:
| I have not regained access to my bitcoin account, in part
| because I have not contacted customer support to do so. I've
| been too busy regaining access and continuing to support my
| client base.
|
| 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.
| ThePowerOfFuet wrote:
| If your crypto was stored on an exchange then this is par for
| the course; rule number one is that if you don't control the
| private keys, the coins are not yours.
|
| You haven't even tried to regain access to it? Instead of
| spending time on HN you might want to reach out to Coinbase.
| Zolt wrote:
| Agreed. Done. "Thanks for taking the time to contact us.
| We're currently receiving a high number of requests so we
| may take longer to respond, but our team is working hard to
| get to every inquiry quickly."
| ysavir wrote:
| > 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.
|
| 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.
| FabHK wrote:
| Or get a domain with catch-all, and a different email for
| every service. Ideally not trivially guessable.
| sometimesshit wrote:
| Coinbase has extensive access to mobile provider data. They can
| see when number ported and what phone the thief uses, but it's
| really hard to make decisions.
| tgsovlerkhgsel wrote:
| I understand that it's hard in the edge cases, but a port
| followed by account recovery within a short period of time
| should be enough of a red flag to immediately lock the
| account.
| sometimesshit wrote:
| > A port followed by account recovery within a short period
| of time should be enough of a red flag to immediately lock
| the account
|
| 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.
| tgsovlerkhgsel wrote:
| If a customer loses the phone, and then _ports_ the
| number instead of replacing it, and also forgets their
| password at the same time... yeah, I think it 's fair to
| give them a bit of a hard time before letting them in.
|
| 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.
| vinay_ys wrote:
| One of the protections enforced in my country is this - for 24
| hours after mobile number porting, all incoming/outgoing sms are
| blocked. And on both the current sim and new sim, notification
| sms are sent to inform the user that mobile number migration is
| occurring. This gives you the opportunity to notice and put a
| stop to it if it was triggered fraudulently. But of course there
| are corner-cases to this. If you are personally targeted in the
| meatspace, then all bets are off.
| inetknght wrote:
| I lost my Microsoft account years ago. I still get emails from
| Microsoft stating that there's suspicious activity on the
| account. I got two just yesterday.
|
| 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.
| saos wrote:
| In the same boat. Really annoyed I can longer access it. The
| process to recovery is a total joke too.
| paulpauper wrote:
| google does the same thing
|
| 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.
| whymauri wrote:
| >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.
|
| 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.
| inetknght wrote:
| > _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?
| indymike wrote:
| This is really interesting because of a few things:
|
| * 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?
| rawgabbit wrote:
| As others have said, it is not that SMS 2FA is insecure; it is
| that thieves have figured out how to defeat it using SIM jacking
| and a bit of facebooking and googling. It is now trivial to
| figure out your home town, your favorite pet, etc. Also as others
| have said, the current alternatives have their problems. What if
| you lose all your Yubi keys? What if your phone was accidentally
| wiped and you never got around to backing it up? You cannot prove
| you are you and so customer support cannot help you. Google,
| Microsoft, and Apple are not known for helping consumers get
| themselves out of this catch-22.
|
| 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.
| unethical_ban wrote:
| I only use 2FA if the service provides me with backup codes
| that I can put in my password safe, which has a unique, long
| password that is stored and backed up in several places.
|
| 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.
| danieljacksonno wrote:
| We have something vaguely similar with "BankID" in Norway. It's
| a bank issued digital ID that submits a 2FA to your phone (not
| through SMS, but through some other system that takes over the
| whole screen - not sure what it is).
|
| 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.
| srhngpr wrote:
| This has been rolled out and in use in British Columbia,
| Canada as well. We have a digital ID app for iOS and Android,
| which you verify your ID with first, then for government
| sites (e.g., health records), you login through this app
| instead - there are no emails, usernames, or passwords
| involved.
| spicybright wrote:
| Absolutely this, but the service should act like a driver's
| license if you want people to actually use it.
|
| 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.
| baybal2 wrote:
| > As others have said, it is not that SMS 2FA is insecure; it
| is that thieves have figured out how to defeat it using SIM
| jacking and a bit of facebooking and googling
|
| 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
| jrochkind1 wrote:
| > As others have said, it is not that SMS 2FA is insecure; it
| is that thieves have figured out how to defeat it using SIM
| jacking and a bit of facebooking and googling
|
| Uh... what does (in)secure mean to you?
| bkdbkd wrote:
| exactly. "its not that the lock is insecure, its just that
| sometimes thieves figure out how to make keys."
| bszupnick wrote:
| Not only is it not secure, it's not a constant for everyone.
|
| I moved countries and I am now locked out of my bank account
| abroad since they verify logins via OTP over SMS.
| artificialLimbs wrote:
| I've signed up with voip.ms, which provides me a pay as you go
| sms number for basically $0/mo. since I only use it for auth.
| lazide wrote:
| Many services go out of their way to detect and block the use
| of VoIP numbers for SMS auth :s
| artificialLimbs wrote:
| What's the reasoning behind that? Maybe to prevent bots?
| toss1 wrote:
| I'd start with VOIP numbers being so easy to spoof... and
| move onto the entire telephone network being insanely
| insecure and unverified, despite decades of efforts to
| link people to telnos -- until they implement actual
| caller-recipient full verification, they've effectively
| got nothing.
| matheusmoreira wrote:
| > until they implement actual caller-recipient full
| verification
|
| Is it even possible to do this at this point? I'd expect
| something like this to fundamentally change the way
| telephone networks work.
| michael_vo wrote:
| For some countries (USA) you can forward your number to a
| google voice number and retain incoming sms. Call forwarding
| isn't possible to my knowledge.
| physicles wrote:
| Porting my number to Google voice before moving abroad was
| one of the smartest things I've ever done (in hindsight), for
| this reason.
|
| I sometimes wonder why Google has kept it running for so
| long, when they're so keen to kill off boring, under-
| performing products.
| njacobs5074 wrote:
| Maybe look into whether you can get a Skype number set up to
| receive the SMSs. Some countries/banks will work with this
| arrangement.
|
| But I feel your pain. It is very frustrating situation to be
| in.
| ThePowerOfFuet wrote:
| Why cancel your old phone number in that country when you still
| have a bank account there?
|
| I suggest a bank which doesn't suck, such as bunq.
| spicybright wrote:
| I would never think my phone # was the only proof of
| identity.
| ThePowerOfFuet wrote:
| If that's what your bank had been using during the login
| flow...
| 2rsf wrote:
| if you immigrate, like I did, but still have some pension
| funds or saving accounts in your home country. Why would I
| want a local phone line?
| ThePowerOfFuet wrote:
| So your bank can send you the SMS you need to sign in
| (which in itself indicates their security is poor).
| snappieT wrote:
| It can be costly.
|
| I moved from Ireland to the US and kept my Irish number
| active - the cost was a EUR5 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.
| ThePowerOfFuet wrote:
| Then it sounds like changing bank is a better answer for
| many.
| snappieT wrote:
| This oversimplifies the situation - if every US bank uses
| SMS and you want to retain a US bank, what do you do?
| ThePowerOfFuet wrote:
| That's such a huge "if" that an alternative immediately
| came to mind:
|
| TransferWise doesn't require a US phone number, but you
| can have a US account number with them.
| Ensorceled wrote:
| Maybe they didn't know they needed a phone number to maintain
| access to the account?
|
| Let's not blame the victim here.
| ThePowerOfFuet wrote:
| The bank is at least equally at fault, if not more so.
| Avamander wrote:
| It all boils down to the fact that the states don't have a
| reliable identity verification system. Can't securely recover
| accounts, have to resort to silly 2FA methods, and so on.
| Havoc wrote:
| It's a major issue in South Africa too with bank accounts being
| raided.
|
| Bank says not my problem if your password got compromised.
| Cellphone provider says not my problem - SMS was never
| advertised/intended as secure.
|
| So the user just has to deal with bank account being drained
| irfwashere wrote:
| Does anyone else here use Google voice for sms 2fa?
|
| You get another number and you should be safe from sim swap
| attacks.
| ddtaylor wrote:
| Recently Mozilla started requiring 2FA for their AMO site used to
| publish addons. I have a few private addons that I develop and
| use, nothing big yet, but I really didn't want to link anything
| up with 2FA over SMS and I'm also trying to reduce my "Google
| footprint" so instead I selected their only alternative that
| doesn't use a centralized third party.
|
| It was a bit complex, but I eventually got Keepass to generate
| the TOTP codes which so far are pretty awesome.
| chris_st wrote:
| Got an email from Heroku last night saying they're discontinuing
| SMS as a 2FA scheme... yay Heroku!
| GhostVII wrote:
| Unless they are requiring everyone to use 2FA, isn't that
| objectively worse than having the option of SMS 2FA? I'm sure
| there are a significant number of people who would just switch
| back to using a password instead of SMS 2FA rather than having
| to get a non-SMS second factor, since it is much less
| convenient than just putting in a phone number.
| chris_st wrote:
| Well... I think that if they don't _require_ 2FA, then, well,
| they don 't require 2FA, and not having SMS is neither worse
| nor better.
|
| 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.
| ncphil wrote:
| Yep. They've been planning that for awhile, hopefully a case of
| "leading by example". For me hardware keys (U2F) with TOTP as a
| backup are really essential. I've purged SMS where I can.
| Unfortunately, too many (like banks) have stopped at SMS and
| email as options -- and that only recently. My (insert name of
| wildly popular open source password manager here) vault is
| secured by U2F with TOTP as a fallback, and I use its TOTP
| feature to secure logins for less sensitive services. Someone
| mentioned building in delays for resets: that's actually how
| both the US IRS and Social Security roll. Last time I reset SSA
| I had to wait for a physical letter with further instructions.
| Inconvenient, but probably a step in the right direction. If
| government intel agencies weren't so uptight about crypto, we
| could all have our own officially issued crypto keys by now.
| But no. The prols can't be trusted -- and don't deserve it
| anyway.
| chris_st wrote:
| For whatever it's worth, the US government has shown itself
| to be spectacularly bad at keeping secrets (proof left as an
| exercise for the reader).
| bouke wrote:
| Making existing accounts less secure by removing a second
| factor is not "leading by example" in my book. Just make me
| pick a different second factor on my next sign-in.
| bouke wrote:
| Not sure if the yay is sarcasm. Heroku will remove existing SMS
| as second factor from all accounts, effectively making those
| accounts less secure. Yay Heroku! (Sarcasm intended)
| chris_st wrote:
| No sarcasm intended at all on my part -- I think this is a
| very good move.
|
| 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.
| bouke wrote:
| Removing 2FA from existing accounts is _never_ an
| improvement in security. As other replies on this post have
| noted, having SMS as 2FA is always better than not having
| 2FA. Heroku is actively harming their user 's security by
| removing 2FA from user's accounts. Some users will not set
| up a new 2FA method on their account, leaving their account
| vulnerable to password attacks.
| dools wrote:
| SIM jacking is pretty easy. In Australia if you know someone's
| mobile number and date of birth you can port a prepaid mobile.
| For postpaid accounts all you need is a bill.
|
| 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)
| platty wrote:
| I had this happen with AT&T. Someone bought a new phone on my
| account with a phone upgrade, they transferred my service to the
| new phone, and I had to go through a ton of headache getting them
| to give me my service back to my old phone and trying to figure
| out what happened.
|
| At the end, they acknowledged it was fraud. Additionally, added
| guards on the account with an additional passcode and wording
| stating that a person must confirm with me specifically before
| anything like transferring services is done again.
|
| It did however blow my mind that something like that could happen
| and if someone intended on getting access to my accounts, the
| situation could have been much worse.
| robomartin wrote:
| I had to go look for how people might be able to hijack the SMS
| system. This led to [0], which was discussed on HN about three
| months ago [1].
|
| Interesting, yet an attacker would have to spend some amount of
| money per attempt. Unless they are targeting high value
| individuals this does not seem a likely threat for the average
| person.
|
| Other methods exist, such as SIM-jacking [2]. I wish the article
| included a list of phones that might be vulnerable to this
| attack. Are iPhone's vulnerable?
|
| And yet, while "free" this still requires a massive automated net
| to be deployed in order to gain some information and then
| socially engineer your way into gaining access to sites and
| services that might be of value.
|
| I guess my question is: How common are these attacks? What's the
| scale of the activity? I have never heard of anyone in my
| immediate and even extended circles having any such issues. OK, I
| have indoctrinated most of my family into not clicking links in
| SMS messages and most of my extended circles are technically
| savvy. What does this look like in the general population?
|
| [0] https://www.vice.com/en/article/y3g8wb/hacker-got-my-
| texts-1... [1] https://news.ycombinator.com/item?id=26468892 [2]
| https://medium.com/auedbaki/how-hackers-hack-phone-using-sms...
| jokethrowaway wrote:
| Very true.
|
| 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.
| Zolt wrote:
| I forgot to include this in my original post. I use the Microsoft
| authenticator application to authenticate my account. My mistake
| was also including my mobile number as an alternative way to
| authenticate my account. I don't know if I was aware of this or
| if Microsoft prompted me for my phone number at one time and I
| did not think through all the ramifications.
| 1cvmask wrote:
| We set up multiple different types of recovery and backup and
| restore options for the saas pass authenticator and password
| manager to let you the individual be able to customize it as
| you wish.
|
| 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.
| myrond wrote:
| Happened to me as well. I found out who the actual people who
| hijacked it due to their poor operational security awareness.
| Found out they did this to someone every 2 weeks. Nobody cared as
| they successfully stole $0. I've watched the news to see if they
| were ever caught; I assume they are still doing it to this day.
| jsnell wrote:
| Your problem is not with SMS as a second factor though. (Unless
| you think the attacker had your password as well). It is with the
| use of SMS as a single recovery factor.
|
| The 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.
| cik wrote:
| Exactly this. Here in Israel, SMS is used extensively as part
| of a multi-factor authentication system. I also require my
| National ID.
|
| 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.
| 2rsf wrote:
| And still numbers are being hijacked even in Israel [1], and
| even in Sweden, where I live now, I swept my SIM without my
| ID being properly checked
|
| [1] https://www.gov.il/he/departments/news/sim
| cik wrote:
| Absolutely. This is the problem - it's not the ideal
| method.
| tinus_hn wrote:
| You can't control some random guy in a provider store giving
| out a new sim for your account, whether maliciously or
| because they were deceived.
| j45 wrote:
| SMS will remain vulnerable as long as the mobile accounts that
| hold them upstream remain vulnerable.
|
| 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.
| LinuxBender wrote:
| I've tried this, but many companies block VoIP numbers for
| MFA/2FA. Some don't. This works with LinkedIn, but not any
| companies I have purchased things from.
| staticassertion wrote:
| If the argument is "but you still have a password" it really
| kind of shows how weak SMS 2FA is. Compare that to a U2F token
| where you can very reasonably remove the password entirely and
| still be just as safe - it is itself just a strong auth
| mechanism, whereas SMS is adding extremely questionable value
| between the ability to phish SMS 2FAs or hijack the number.
|
| 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.
| contravariant wrote:
| You can only use a U2F token at the only factor when it's
| acceptable for you to temporarily lose control of the
| account.
| baybal2 wrote:
| I want warn people about U2F.
|
| 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.
| StavrosK wrote:
| > Compare that to a U2F token where you can very reasonably
| remove the password entirely and still be just as safe
|
| 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.
| withinboredom wrote:
| But that isn't portable. If you lose your device or just
| reinstall the OS, you can never login again.
| StavrosK wrote:
| Sure, but that's why you add multiple devices/keys to
| your account. Reinstalling the OS should be fine.
|
| 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.
| UncleMeat wrote:
| SMS adds friction to password stuffing. Given that a
| gazillion people do not use unique passwords, this has some
| value.
|
| 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.
| Wowfunhappy wrote:
| > Compare that to a U2F token where you can very reasonably
| remove the password entirely and still be just as safe
|
| 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.
| esolyt wrote:
| I'm glad someone is bringing this up.
|
| 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.
| benjohnson wrote:
| I keep an old phone around with a duplicate Authy setup.
| I also photograph the 2FA code or QR code and print it to
| a safe place.
| geephroh wrote:
| Services like Authy address some of the loss of device
| issue, and always a good idea to have a backup token
| (e.g., yubikey) physically escrowed somewhere like a
| safe-deposit box.
|
| But it is a whole lot of extra work to set up and
| maintain long-term, even with the best intentions.
| ncann wrote:
| +1 for Authy. Just get a used cheap Android phone for
| like $30 and use it as the backup device for Authy and
| never fear about losing your 2FA device again.
| andmalc wrote:
| Password managers such as 1Password and Bitwarden can
| save and fill in TOTP codes. Maybe not perfect security
| but a big win for convenience and loss prevention.
| NotEvil wrote:
| I have received advice from way to many people to not use
| your password manager as a 2nd factor be ause 1) It's
| actually become the only point if failure (your pw
| getting hacked). 2) Both factors protected and saved on
| the same spot
| brewdad wrote:
| I use BitWarden for my passwords while storing my 2FA
| backups in KeePass for exactly this reason.
| deckard1 wrote:
| 2FA goes one of two ways:
|
| 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?
| dageshi wrote:
| Don't most 2fa systems have recovery codes? You print em
| off or encrypt them with a one time password?
| LinuxBender wrote:
| And the site has to support U2F. U2F is a great standard
| but almost none of the businesses I interact with support
| it. There are maybe 3 banks in the US that support it, but
| not mine.
| FabHK wrote:
| I don't understand why banks and businesses don't
| outsource the whole authentication business to someone
| that does nothing else, and then does proper 2FA (maybe
| with a choice of security levels), and supports as many
| standardised solutions as possible.
| jjav wrote:
| You can also "loose, etc" the phone so it is equally weak
| on that front. Except the SIM can be hijacked, so SMS is
| strictly worse and never better.
|
| 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.
| tgsovlerkhgsel wrote:
| The advantage with the phone is that the web site
| operator can pawn off the difficult recovery part on your
| mobile provider (go there, show ID, get a new SIM).
|
| 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.
| rocqua wrote:
| Its generally not "second factor authentication" but
| 2-factor authentication. The idea is that you have 2
| separate authentication factors. Preferably both with
| decent security.
|
| 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)
| cortesoft wrote:
| No, it sounds like coinbase used email recovery, but his
| email provider used SMS recovery.
|
| 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.
| tgsovlerkhgsel wrote:
| One of the problems here is that few sites support U2F, and
| even fewer support it properly.
|
| 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).
| staticassertion wrote:
| > Yeah, and it requires me to use a U2F token, which I can
| loose, etc.
|
| 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.
| darkwater wrote:
| > In which case there are much safer recovery mechanisms
| available. For example, a second U2F token, or
| handwritten backup codes.
|
| 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.
| staticassertion wrote:
| > 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.
| Wowfunhappy wrote:
| A phone's TPM is the _only_ U2F token that 99% of the
| world owns, assuming they own one at all.
| staticassertion wrote:
| Yes, as I've said, availability is the problem to solve.
| We should be shipping U2F tokens wherever we can. I'd
| like to see schools that require students to use GSuite
| and other U2F supporting sites giving students tokens for
| free. I'd like to see banks giving their customers
| tokens. I'd like to see companies giving them to
| employees.
|
| 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".
| tsimionescu wrote:
| Most people don't own two phones though, and wouldn't
| think to have two separate U2F tokens.
| jsnell wrote:
| But that is my entire point. SMS as a second factor is
| purely additive. It cannot reduce security.
|
| 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.
| tialaramex wrote:
| > SMS as a second factor is purely additive. It cannot
| reduce security.
|
| 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.
| jsnell wrote:
| Here's the same story without 2FA:
|
| "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.
| tialaramex wrote:
| But in your revised story I don't receive reassurance
| that everything is going as planned. That's what I'm
| getting at, the SMS step is _reassuring_ even though it
| actually shouldn 't be.
| jsnell wrote:
| If there is no 2FA, not being asked for a confirmation
| code is things going as normal. Also, it's totally
| irrelevant whether the user gets cold feet since in the
| password-only world they've just handed away the keys to
| the kingdom.
| jjav wrote:
| > But that is my entire point. SMS as a second factor is
| purely additive. It cannot 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.
| chc wrote:
| They specifically said "SMS as a second factor." What
| you're discussing here is a completely different
| different use of SMS that nobody is arguing in favor of.
| jjav wrote:
| As I mentioned, there is no guarantee any site is going
| to never allow use of that phone, once it's on file, to
| bypass authentication. Even if they don't right now. So
| adding a phone to an account increases your risk in a way
| you can't control. The only guaranteed way to avoid it is
| to never have a phone# on file.
| staticassertion wrote:
| > SMS as a second factor is purely additive. It cannot
| reduce security.
|
| 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.
| rocqua wrote:
| > Some form of trust that can be bootstrapped again from
| scratch.
|
| 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.
| jsnell wrote:
| I don't really understand why you think I'm advocating
| for SMS as the only factor, when I very clearly wrote the
| exact opposite.
|
| 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.
| sgerenser wrote:
| Except in practice, most providers (even those that
| should know better, like Google) allow use of SMS,
| ostensibly set up as a "second factor," to be used for
| account recovery without knowing the password. Making it,
| in practice, 1FA.
| paulpauper wrote:
| It can reduce security if password can be reset with SMS
| FabHK wrote:
| That's the whole point of GP:
|
| SMS is perfectly fine as a _second_ factor, and terrible
| if it can serve as the _only one_ factor.
| Wowfunhappy wrote:
| > 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.
| staticassertion wrote:
| > 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.
| Wowfunhappy wrote:
| > 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.
|
| 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.
| staticassertion wrote:
| > So it's better to not consider that information at all?
|
| 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.
| bun_at_work wrote:
| What about an authentication app? Google Authenticator or
| something similar can be installed on the phone which is
| necessary for SMS, improves the security more than SMS, and
| doesn't suffer from the problem of losing it, at least not
| more than SMS auth does.
| FabHK wrote:
| When your phone is lost or stolen, you buy a new phone
| and go to your telco provider to get a new SIM with your
| number. SMS 2FA continues to work. Your Authenticator
| secrets are gone with the phone, and you're locked out.
|
| (Unless you use a solution like Authy with multiple
| devices, which strikes me as the most sensible solution.)
| filoleg wrote:
| It blows my mind that Google Authenticator still doesn't
| have a multi-device sync feature (or even a "recover from
| backup" feature on iOS for that app, because I think they
| added it recently to Android; just "recover from backup"
| alone would have been sufficient to convince me not to
| switch).
|
| 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.
| u801e wrote:
| I really wish that web browsers had worked on the UI for
| generating certificate signing requests and importing
| certificates and that websites had 2FA via
| username/password along with client-side TLS certificate
| for authentication.
|
| 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.
| baybal2 wrote:
| It had it! HTML 5 keygen tag
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/ke...
|
| 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
| jjav wrote:
| Yes! This was a very good solution. Built right into the
| browser, very convenient. We built a related CA product
| back in the 90s and were issuing client certs on smarts
| cards via the browser. Plug in smartcard and browser
| could automatically authenticate to all services. Take it
| out and go home.
| the_snooze wrote:
| SMS is better than nothing, but you have a bunch of other
| better fallback alternatives before you should rely on it.
| You can support the enrollment of multiple hardware tokens
| (i.e., you keep one at home, and one on your person). You
| can have online push login approvals. You can have a TOTP
| code generator.
| paulryanrogers wrote:
| > You can support the enrollment of multiple hardware
| tokens (i.e., you keep one at home, and one on your
| person).
|
| 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.
| tialaramex wrote:
| WebAuthn explicitly _tells_ Relying Parties (ie web
| sites) to all do this. All the services _I_ use which
| offer WebAuthn or its predecessor U2F support multiple
| named hardware tokens and I enroll at least my Yubico
| branded device and one more at such sites. For those I
| use from a phone, the phone itself is enrolled.
|
| 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.
| UncleMeat wrote:
| TOTP is the one that makes the least sense to me. It is
| also weak to phishing (extremely common) but adds
| protection against SIM-swapping (comparatively very
| rare). It also has almost all of the downsides of U2F (a
| pain in the ass if you lose your device).
| nucleardog wrote:
| TOTP has the downsides of U2F, but those downsides are
| comparatively easier to mitigate.
|
| 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.
| derefr wrote:
| > a pain in the ass if you lose your device
|
| 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.
| UncleMeat wrote:
| > Every modern TOTP app is cloud-synced
|
| 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.
| derefr wrote:
| > Symantec VIP
|
| See https://www.reddit.com/r/1Password/comments/8yey6y/ho
| w_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.
| UncleMeat wrote:
| I do use a similar approach to backup the Symantec secret
| - but what percentage of users do you think are capable
| of doing this? 0.1%?
|
| > 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.
| staticassertion wrote:
| TOTP is an improvement over SMS in that identity is not
| tied to a phone number, which has been proven over and
| over again to be a terrible indicator of identity.
| 1cvmask wrote:
| The option for a delay of is great. The option of adding a
| custom security question/password etc. is even better. The
| option of completely turning off recovery is also great. The
| ability to have your solution on multiple devices without a
| need for a mobile phone number based recovery is great as well.
|
| 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.
| 1cvmask wrote:
| More details of customizable recovery and backup and restore
| is available here with visuals:
|
| https://blog.saaspass.com/saaspass-password-manager-
| authenti...
| vitaflo wrote:
| On Twitter you can remove your phone number after the fact
| tho. In fact most sites that req a phone number to sign up
| etc allow you to remove the phone number later if you choose.
| vlovich123 wrote:
| I got my Uber account taken over this way and I wasn't using my
| cell for recovery of anything. SMS is terrible for all these
| purposes
| fulafel wrote:
| This kind of arrangement is often mockingly, but accurately,
| called 1/2 factor authentication.
| StavrosK wrote:
| > The 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.
|
| No, SMS shouldn't be a single factor, period. It doesn't prove
| much, and is insecure, as the current post shows.
| sfteus wrote:
| I've posted before on here about my experience getting SIM
| swapped and how quickly someone was able to gain access to a
| bunch of my accounts. If I hadn't been at home and looking at
| my phone while it was happening, it could have been much worse,
| but thankfully I was able to get in and terminate most of their
| login sessions before too much damage was done.
|
| 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.
| exabrial wrote:
| There is no situation where it is good at anything.
| birktj wrote:
| This. SMS is a great second factor and is perfectly suitable to
| prevent the main attack that you want second factors to
| prevent: that is if your password appears in a password list
| for any reason it should stopp anyone from just running away
| with your account. Note that if you are targeted directly SMS
| is not going to help you much but in this case maybe your
| password can (depending on the capabilities of the attacker).
|
| 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.
| dheera wrote:
| SMS is not a good second factor, even as a second factor.
|
| 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.
| rsgrn wrote:
| How do you direct SMS to the online interface?
| dheera wrote:
| Twilio
| raesene9 wrote:
| FWIW I wouldn't regard SMS as a good 2nd authentication factor
| either, for the same reasons as this issue, it's too easy to
| get a carrier to transfer a number to an attacker.
|
| 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.
| addingnumbers wrote:
| The problem is with most online services, the only second
| factor allowed is SMS.
|
| 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!"
| raesene9 wrote:
| I didn't say it was worse than just password, I said it was
| a bad second factor, which it is.
|
| SMS 2FA was vaguely reasonable before TOTP applications and
| smartphones capable of running them were widely available.
| That's no longer the case.
| iso1210 wrote:
| What's the recovery process when your phone gets stolen,
| or you drop it?
| raesene9 wrote:
| For me, for TOTP, I use one that backs up to iCloud. that
| obviously weakens the security, but increases the
| availability.
|
| With some applications, you can add additional devices,
| so you can add multiple, if you have 'em.
| addingnumbers wrote:
| A bad second factor is better than no second factor.
|
| 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.
| raesene9 wrote:
| others may have suggested that, I did not :)
| profsnuggles wrote:
| If someone can exploit your SMS, it's possible they can
| use that to social engineer their way into a password
| resets with services. (I forgot may password but I still
| have my phone.) So I would say a bad second factor can be
| strictly worse than no second factor.
| addingnumbers wrote:
| You're describing single factor, not two factor. If you
| can change the password with SMS alone, it's not multi-
| factor. I plainly stated that exception two comments ago.
| jjav wrote:
| You're incorrectly assuming that you can predict a site
| will never allow password reset via SMS only.
|
| 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.
| profsnuggles wrote:
| Except you have no way of knowing if that will be the
| case ahead of time. Unless the first thing you do after
| enabling 2FA is to social engineer a password reset for
| your account? Even then that doesn't guarantee that there
| isn't a more clueless service rep that will make a
| mistake.
|
| 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.
| FabHK wrote:
| But then let's please move the discussion from "Is SMS a
| good or bad second factor?" to "SMS is a mediocre second
| factor, and a terrible single factor. For this service,
| is it a second or single factor?"
| VRay wrote:
| Basically every service I've used that requires SMS will
| use it as the sole authentication factor for resetting your
| password.. It's brutal
| realusername wrote:
| SMS is the only "second factor" that you can't control at
| all, your phone number can be changed from the phone
| company at any point, disabled, or suddenly refuse to work
| in a foreign country (all of those three happened to me).
|
| 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.
| UncleMeat wrote:
| TOTP is phishable, which is a way way way more common attack
| than sim swaps.
| 2rsf wrote:
| phishable how? "your account has been hacked, please
| provide us a TOTP code"?
| UncleMeat wrote:
| 1. Somebody loads fakebank.com.
|
| 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.
| sgerenser wrote:
| Couldn't this entire scenario play out exactly the same
| with SMS codes?
| UncleMeat wrote:
| Yes.
|
| 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.
| dheera wrote:
| TOTP is far, far better for travellers who need to swap
| their SIM cards frequently, or need to work out of places
| with internet access but no cell reception.
| UncleMeat wrote:
| Sure. I'm not opposed to supporting it. It is just weird
| to me to see people pushing for it with seemingly equal
| vigor as U2F.
| dguo wrote:
| This is certainly a vulnerability, but it also depends on
| how you get your TOTP codes. I use Bitwarden's browser
| extension to get mine, and if the domain is incorrect,
| the extension won't present me with the code. I think
| this is a decent level of protection from phishing.
| tialaramex wrote:
| I encourage you, as an exercise at least, to think about
| what you'll do when it doesn't work.
|
| 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.
| raesene9 wrote:
| Sure, no security measure is perfect. Hardware tokens are
| likely to have better properties than TOTP, which has
| better properties than SMS, which has better properties
| than nothing.
|
| you can phish SMS exactly the same way you can phish TOTP,
| I'd say :)
| UncleMeat wrote:
| TOTP is marginally safer than SMS.
|
| 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.
| mrweasel wrote:
| > TOTP or hardware tokens don't generally suffer from the
| same problem.
|
| 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".
| PeterisP wrote:
| It is safe to use the same U2F token for many sites, that's
| not an issue. Having a backup token is very useful, but
| apart from that, a single hardware token (not custom -
| standards are good) can easily be used to secure all your
| accounts.
| mrweasel wrote:
| Assuming that the sites allow you to change the token
| manually?
| tialaramex wrote:
| I've never seen a site that didn't have at least this.
|
| 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.
| dheera wrote:
| The only thing I wish is that more sites support multiple
| tokens, since tokens can get lost.
|
| 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.
| tialaramex wrote:
| Again, _other than AWS_ which "more sites"?
|
| 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.
| dheera wrote:
| Twilio, Kraken, Paypal, Gusto, Bittrex, Coinbase, ...
| tialaramex wrote:
| But none of these support U2F or WebAuthn at all. The
| problem isn't that they need to support "multiple" tokens
| except in the sense that they don't support any at all.
| dheera wrote:
| They all support TOTP and some (such as Kraken) support
| U2F.
|
| Point is whether it's U2F or Web'n'Auth or TOTP they need
| to support multiple keys.
| tialaramex wrote:
| Kraken's own support site says that they do not in fact
| support U2F.
|
| 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.
| aarreedd wrote:
| You can request that your mobile provider put a port freeze and
| SIM lock on your account and require you to be in-store with a
| valid photo ID to transfer your number to another device.
|
| https://help.coinbase.com/en/coinbase/privacy-and-security/d...
| xphos wrote:
| Yeah but if that's not the default 2 factor authentication is
| not secure and its an illusion of safety. For companies and
| groups to claim its gives you all this security when it doesn't
| follow through even in the default case is misleading. No shade
| on you but your talking about a lot of hops to go thru just to
| make someones broken model work.
| rvz wrote:
| I made a point about this previously and unfortunately, your
| situation is exactly the reason why SMS authentication should be
| avoided, since these sort of attacks are now becoming common. [0]
|
| [0] https://news.ycombinator.com/item?id=27311641
| eslaught wrote:
| Part of the issue here that I don't see people addressing is that
| SMS as an only-factor recovery tool is often not optional. I hit
| a case like this just the other day: the service would not allow
| me to log in _at all_ without adding an SMS number. This is
| becoming increasingly common.
|
| The irony is that my security is now worse. At least my password
| was randomly generated.
|
| I'm not sure what there is to do about this, other than educating
| as broadly as we can and hope that engineers advocate in their
| own organizations to change this.
| 3np wrote:
| I really hope that I am not the only one requesting businesses
| to not do this when I encounter it. It may be the only way to
| get it to stop.
|
| Open a case with customer service and represent it for what it
| is; a security hole that prevents you from using the service.
| paulpauper wrote:
| that is because google and other companies derive more $ from
| your number than protecting your privacy/security
| kyle-rb wrote:
| Google doesn't require SMS. They often ask me when I log in,
| but I can always hit 'skip', which I do because I'm scared of
| this exact case.
| tgsovlerkhgsel wrote:
| This is not universally true. If Google decides that your
| account looks suspicious, either at creation or a later
| date, you are unable to access it until you provide a phone
| number.
|
| You also used to be unable to set up a U2F/FIDO 2FA without
| first setting up SMS 2FA (but you could delete the phone
| number from the account later). Not sure if that's still
| the case.
| paulpauper wrote:
| The worst part is, Coinbase will not cover your losses. They have
| absolved themselves of any responsibly for users being hacked,
| only if they [coinbase] gets hacked.
| tgsovlerkhgsel wrote:
| Since I wasn't sure if this is just what their ToS claim or how
| it's handled in practice, I googled a bit, and found this case:
|
| https://finance.yahoo.com/news/coinbase-hacked-accounts-get-...
|
| So this indeed seems to be how Coinbase handles it.
| nodesocket wrote:
| Worst part, I mean that's the majority of the risk of crypto.
| These aren't government backed accounts, why would there be
| insurance.
| TheHippo wrote:
| This seems more of an problem when living in the USA than an SMS
| problem. I'm in Germany and there is no way someone gets a new
| SIM card without someone checking the persons personal ID.
| UncleMeat wrote:
| That isn't 2FA. That is a single factor recovery process. SIM-
| swapping only defeats SMS-based 2FA if the attacker _also_ has
| your password, which is difficult to accomplish if you are using
| good passwords that are unique.
| Zolt wrote:
| I had to remove this detail from my original post as it was too
| long:
|
| 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.
| UncleMeat wrote:
| The "industry standard" is that SIM-swapping it not
| difficult. Arvind Narayan's group at Princeton demonstrated
| this pretty convincingly. This isn't unique to Boost.
| rocqua wrote:
| Does coinbase really allow account recovery with just an SMS?
| It seems to me like the attacker must have had more than just
| control over your SMS number.
| TwoBit wrote:
| Yeah the attacker now also has email control.
| grlass wrote:
| I don't have a source to hand, but I've heard from other
| post-mortems that in SIM-jacking attack the carrier has been
| socially engineered into not bothering with the pin, ongoing
| court cases RE negligence perhaps on-going.
| grishka wrote:
| If they're able to issue a new SIM card without the system
| requiring them to enter the PIN first, then it's a very
| terribly designed system.
| mook wrote:
| They have to be able to issue a new SIM card without a
| pin in the case of a lost phone though. In that case they
| should probably check government identification, of
| course, and not be available remotely.
| grishka wrote:
| I thought you needed the PIN if you wanted that, too? As
| in, if you lose your phone and don't have the PIN set up
| with your carrier, you've lost your number and can't
| restore it.
| throwaaskjdfh wrote:
| With just a SIM swap, isn't it possible for an attacker to
| reset the password on your main email account (e.g. gmail) via
| the phone, then from there reset the password on your money
| account through the stolen email?
| cassianoleal wrote:
| Sorry you went through all that, and even more sorry that you'll
| probably be dealing with the fallout for quite some time.
|
| 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.
| aiisahik wrote:
| Question: Have people used Google Voice SMS accounts or Twilio
| SMS accounts for 2FA? Would that be more secure?
| irfwashere wrote:
| I have heard that this is actually better and more secure.
| Google voice I think isn't susceptible to social engineering
| attacks like typical phone carriers. Also it's a smarter move
| to have a separate phone number that isn't related to what a
| hacker might be able to find out about you just doing basic
| search engine queries.
| PascLeRasc wrote:
| For anyone in the US wondering, Ting and Google Fi both allow
| authenticator-exclusive 2FA. I'm very happy with Ting.
| sometimesshit wrote:
| But the banks and crypto exchanges are blocking VOIP numbers
| like Google's
| 3np wrote:
| What really grinds my gears is the seemingly unstoppable global
| transition towards SMS to a mobile phone number as means of
| identifying an individual, conflated with "security" through
| 2FA/account recovery, with this as the only option.
|
| This is especially popular within Fintech.
|
| Wise (formerly Transferwise) recently started requiring 2FA for
| signing in - SMS is the one and only option. Revolut requires it
| for acknowledging transactions and changing/viewing debit card
| info.
|
| That legacy banks do this is expected, but I'm really concerned
| about this trend among newer global and big actors who otherwise
| present themselves as modern.
|
| I strongly urge other users here to reach out to customer support
| of these companies and request them to supplement this with some
| other more secure means of 2FA, such as TOTP (hey, we gotta take
| what we can get), U2F, or Webauthn.
| FabHK wrote:
| Super annoying, especially when (prior to the pandemic) I
| traveled a lot and had a new SIM every month or two. Insanity.
| potatoz2 wrote:
| Wise supports 2FA through their app (similar to what Google
| does, with a prompt).
| oezi wrote:
| Well, the European PSD2 has forbidden the use of SMS TANs last
| year for banking applications while requiring much more
| stringent 2FA use (for account balances more than 30 days in
| the past for instance).
|
| So, I would say quite the opposite to unstoppable.
| cromka wrote:
| Yep, and the banks are literally reaching the deadline as we
| speak. All my EU banks are notifying me that within a week or
| so the SMS codes will stop working, and their mobile app will
| be required for 2FA.
| tgsovlerkhgsel wrote:
| And because it has not required some open standard as a
| replacement, I now have hundreds of MB of different bloatware
| bank apps on my phone, each of which I have to use in a
| slightly different way when logging into my bank accounts,
| usually with scanning barcodes or remembering yet another
| PIN. Migrating to a new phone is a nightmare.
|
| For extra convenience, PSD2 also mandated a logout after 5
| minutes of inactivity.
|
| Some of the ideas behind PSD2 are great, but the outcome is
| about as good as the cookie directive.
| oezi wrote:
| Absolutely agreed. I expect consolidation to happen in the
| next couple of years on this. Banks who do it well, will
| win customers.
| tgsovlerkhgsel wrote:
| I've only seen it get _worse_ , and I don't expect that
| to change.
|
| One of my apps where I spend money on a regular basis
| (always similar small amounts, always from the same
| phone, usually from the same IP) constantly triggers 2FA
| via my banking app. Even as an informed customer, I have
| no idea whether to blame that app, their payment gateway,
| Visa/Mastercard, or my bank (that issued the credit card)
| for that bullshit.
|
| The previous situation (banks absorb the fraud) seemed
| much better for me as the customer, and banks stuck with
| it. PSD2 made it so that customers _can 't_ pick their
| bank based on which is more convenient, by making them
| all at least _roughly_ equally inconvenient. Few people
| will bother to change banks over this, and even fewer
| banks will feel enough pressure to actually improve.
| calltrak wrote:
| Quite right. The other thing is people can use fake numbers like
| https://fakenum.io to bypass phone verification!
| swiley wrote:
| Not only is SMS two factor authentication not secure, it
| _weakens_ the security of accounts it is enabled on.
|
| 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.
| teekert wrote:
| Can you explain how I'm weaker with 2FA via SMS than without
| 2FA? I agree SMS is not good 2FA but your statement is more
| extreme.
| Zolt wrote:
| If I didn't have SMS-2FA enabled, they would not have been
| able to take control of my email address without guessing the
| password.
| [deleted]
| StavrosK wrote:
| Because companies routinely and silently use SMS 2FA as SMS
| 1FA.
| ascar wrote:
| But that's not an inherent problem of SMS 2FA. It's just
| bad implementation.
| StavrosK wrote:
| No, the inherent problem of SMS is that it can be
| stolen/redirected. Given that, and given that companies
| are too eager to use it as 1FA, you shouldn't use it.
|
| 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.
| rocqua wrote:
| The unstated point here is that SMS as a second factor very
| often leads to companies using SMS as an alternative factor.
| This is what makes giving companies your mobile number for SMS
| 2FA a risky proposition.
| headmelted wrote:
| I'm not sure it's true that Google insists on using it. Sure,
| they'll use it as a second-factor by default - but you're not
| obligated to use it, can use app-based authentication, and can
| use MFA with a hardware key too.
| UncleMeat wrote:
| Yup. My Google account will not use SMS as a recovery method.
| U2F with backup codes is all I have enabled.
| scottmcdot wrote:
| Having had this almost happen to me, I always strongly recommend
| that you remove your phone number from Gmail as a recovery
| method. And then go and test it out to double check.
|
| SMS 2fa is okay but SMS recovery is not okay and high risk.
|
| It's also ideal to have obscure email addresses used for, say,
| coinbase so that in the data dump they they likely have,
| containing your email to phone number mapping, points them to the
| email address not linked to coinbase.
| rsync wrote:
| You're thinking about this wrong.
|
| 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.
| sabhiram wrote:
| If you have to use it, do so on a non-portable phone number.
| aphextron wrote:
| Nothing is secure against a determined targeted attack. That's
| why we have layers of security. SMS 2FA adds a layer of
| protection against random attacks, and for that it works great.
| It should never be solely relied upon for high value accounts.
| loteck wrote:
| This continues to be debated by so many, but like this person,
| the debate is meaningless in the face of realities. I'd refer
| everyone back to @taviso's work up of SMS "2FA". [0]
|
| 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...
| sometimesshit wrote:
| To the OP,
|
| Please don't use cheap providers like Boost. I have done audit
| and I found Sprint to be superior; however, they got merged with
| T-Mobile now. Sprint was the best provider that prevented most
| hijacks.
| spicybright wrote:
| That's pretty neat, can you describe what you check when
| auditing a network?
| exabrial wrote:
| Yet Apple, SendGrid, any many other require it.
| matheusmoreira wrote:
| Coinbase has no other security options? I have passwords, email,
| SMS, mobile app _and_ a hardware token. Binance actually makes me
| input every single code under a 60 seconds time limit.
| zachrose wrote:
| SMS 2FA isn't secure, but what about a small retail/delivery
| business that uses SMS as the only means of authentication?
|
| 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.
| arthurcolle wrote:
| Were you at the Bitcoin 2021 Conference? I saw many people acting
| shady, looking over people's shoulders as they were using
| Coinbase, other wallets. Do you think there's any way this might
| be related? (Obviously moot if you weren't there...)
___________________________________________________________________
(page generated 2021-06-09 23:01 UTC)