Using Phones/SMS as 2FA – Why I am not a believer(dcid.me)
dcid.me
Using Phones/SMS as 2FA – Why I am not a believer
http://dcid.me/notes/2013-apr-19.html
15 comments
In the case he cited with CloudFlare, the phishing the voicemail was a pretty effective attack vector. Also, where does he tie PIN weakness to SMS interception? They're uniquely vulnerable.
> Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account.
I think you're mitigating one set of risks while adding others.
EDIT: just want to add, I do think UX should be a primary concern of security; I just disagree with your analysis of his post.
> Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account.
I think you're mitigating one set of risks while adding others.
EDIT: just want to add, I do think UX should be a primary concern of security; I just disagree with your analysis of his post.
> EDIT: just want to add, I do think UX should be a primary concern of security; I just disagree with your analysis of his post.
Fair enough. I think the interesting thing to debate is his conclusion: that two factor auth using SMS is so flawed as to be avoided completely. That's complete nonsense.
Fair enough. I think the interesting thing to debate is his conclusion: that two factor auth using SMS is so flawed as to be avoided completely. That's complete nonsense.
Oh really? You think that login+password is a trade of equal risk with login+password+sms? Sorry, but the second is clearly has much less risk.
Twitter introduced SMS authentication as a second factor. Do you really think that their number of fraudulent logins for users protected by that second factor hasn't gone down to near zero?
Twitter introduced SMS authentication as a second factor. Do you really think that their number of fraudulent logins for users protected by that second factor hasn't gone down to near zero?
I think some of the use-cases are getting mixed, including by myself and by the author.
I do agree that 2FA, even with cell-phones, will improve the security of the web interface. The CloudFlare breach was caused by using the phone as an independent authenticator (overriding the password) which is not 2FA, as I understand it.
And I agree, the likelihood of SMS interception or spoofing during the verification process seems pretty slim. I'm going to bow out to the security experts at this point.
I do agree that 2FA, even with cell-phones, will improve the security of the web interface. The CloudFlare breach was caused by using the phone as an independent authenticator (overriding the password) which is not 2FA, as I understand it.
And I agree, the likelihood of SMS interception or spoofing during the verification process seems pretty slim. I'm going to bow out to the security experts at this point.
IIRC, GSM has been cracked. I'm not an expert, so I'm not sure how this affects SMS, but as SMS is done via a control channel (that was not originally intended to be used for text messaging), I'm assuming that there are no extra protections there.
Granted, this requires physical proximity though, which definitely raises the bar for any attacker.
Granted, this requires physical proximity though, which definitely raises the bar for any attacker.
> Security is about systems
That should be the top comment. Having done force protection for an aircraft carrier before, during, and after 9/11, it's all about systems. We involved nation-states in this. All our systems and all their systems. It took months if not years of planning, advance trips, meetings in SCIFs and prestaging assets to bring one of those into a foreign port. Lasers, standoff air defense, dolphins, guys in in cafes "reading the paper". Training 2000 sailors on .50 cal, shotgun, 9 mm. Boat teams. Here's us getting underway from Virginia a week after 9/11:
http://m.usni.org/magazines/proceedings/2001-12
People with no dog in the fight, famously the older warrant and limited duty officers, guys who came up through the ranks for 30 years, would continuously poo-poo my plans. "What if this...." "What if that..."
Toward the end of my tour, the fleet force protection officer, a senior SEAL commander, drug my counterpart from another ship in, an old warrant officer who had been doing physical security since before I was born. The SEAL drilled our team on scenarios in front of this other guy for an hour. Then he turned to the warrant and said "These guys might take the first hit, but I know what they're going to do. I can count on them. I can plan around what they'll do. I have no idea what your ship is going to do. Fix it."
Screw the what-iffers, but make sure you can annihilate their what if scenario twice before it ever comes to that. Take ownership of you defense. Take you job personally. Use the what-iffers for the cheap war gaming they offer, and then don't worry about them.
Get everyone in your organization on board with your plan. Make sure you know who has the authority to pull which triggers, and make sure they're available on the necessary timeline, or devolve that authority to people who are. But don't let the intern have so much authority he can inadvertently start a war.
Know what your internal and external reporting requirements are, and why. For example, I'm willing to bet the security of gmail is considered a national security priority at this point. Even if no one in DC can do a damn thing about it. It's been wargamed, and the Pentagon battle watch commander can get a googler with need-to-know on the phone in under a minute. If that googler doesn't know that, he probably ought to have figured out why.
That should be the top comment. Having done force protection for an aircraft carrier before, during, and after 9/11, it's all about systems. We involved nation-states in this. All our systems and all their systems. It took months if not years of planning, advance trips, meetings in SCIFs and prestaging assets to bring one of those into a foreign port. Lasers, standoff air defense, dolphins, guys in in cafes "reading the paper". Training 2000 sailors on .50 cal, shotgun, 9 mm. Boat teams. Here's us getting underway from Virginia a week after 9/11:
http://m.usni.org/magazines/proceedings/2001-12
People with no dog in the fight, famously the older warrant and limited duty officers, guys who came up through the ranks for 30 years, would continuously poo-poo my plans. "What if this...." "What if that..."
Toward the end of my tour, the fleet force protection officer, a senior SEAL commander, drug my counterpart from another ship in, an old warrant officer who had been doing physical security since before I was born. The SEAL drilled our team on scenarios in front of this other guy for an hour. Then he turned to the warrant and said "These guys might take the first hit, but I know what they're going to do. I can count on them. I can plan around what they'll do. I have no idea what your ship is going to do. Fix it."
Screw the what-iffers, but make sure you can annihilate their what if scenario twice before it ever comes to that. Take ownership of you defense. Take you job personally. Use the what-iffers for the cheap war gaming they offer, and then don't worry about them.
Get everyone in your organization on board with your plan. Make sure you know who has the authority to pull which triggers, and make sure they're available on the necessary timeline, or devolve that authority to people who are. But don't let the intern have so much authority he can inadvertently start a war.
Know what your internal and external reporting requirements are, and why. For example, I'm willing to bet the security of gmail is considered a national security priority at this point. Even if no one in DC can do a damn thing about it. It's been wargamed, and the Pentagon battle watch commander can get a googler with need-to-know on the phone in under a minute. If that googler doesn't know that, he probably ought to have figured out why.
"No 2FA. If the only option available is SMS or call-based authentication, do not use 2FA."
I see no problem with password + SMS or password + phone. The big problem is that some companies think that their second factor overrides the first factor, and choose a weak second factor. 2FA must be an && operation, not an || operation, for all modes of authentication. Otherwise, you are exactly right, and attackers will compromise the weakest link in the chain.
I see no problem with password + SMS or password + phone. The big problem is that some companies think that their second factor overrides the first factor, and choose a weak second factor. 2FA must be an && operation, not an || operation, for all modes of authentication. Otherwise, you are exactly right, and attackers will compromise the weakest link in the chain.
Agreed. If BOTH are required than even if the second factor is relatively weak, it's still better than password-only.
If both are not required it's not a second factor. Two factor is something you know (password) plus something you have (a phone number).
[deleted]
If you have the option to use RSA SecurID or Gemalto
devices (used by Amazon), use them first.
Any system where the manufacturer has a copy of the secret key on the token is theoretically vulnerable to this attack.
Reminder also that OTP is NOT a strong factor, anyways.
Even if the manufacturer doesn't hold the secret seed (i.e. the device lets you regenerate it - vendors usually don't let you do that so that you're forced to buy again from them all the time).. so yes, even if they don't hold that secret seed, the target servers hold them.
There is no encrypted version of the secret seed. There is no hashed version. You and the opposite party (the server you authenticate to) both have to be in possession of the secret seed.
That means if any server containing those keys is compromised, your OTP token is suddenly just paperweight (yeah, people like these crappy analogies, i heard.)
Using something like an opengpg smartcard and true challenge/response type authentication is much better than the "2FA" provided by password + OTP.
Something you have (the keys on the smartcard), something you know (the passphrase to decrypt those keys), the key never leaves the smartcard, nobody else has your key.
There is no encrypted version of the secret seed. There is no hashed version. You and the opposite party (the server you authenticate to) both have to be in possession of the secret seed.
That means if any server containing those keys is compromised, your OTP token is suddenly just paperweight (yeah, people like these crappy analogies, i heard.)
Using something like an opengpg smartcard and true challenge/response type authentication is much better than the "2FA" provided by password + OTP.
Something you have (the keys on the smartcard), something you know (the passphrase to decrypt those keys), the key never leaves the smartcard, nobody else has your key.
Something you have, something you know ... I can see the utility in requiring just those. But I've found it useful to get messages from service providers when, for instance, my ATM card is used, or when I login at a new computer. So I'd like to add to that list "something you monitor" whether through SMS-based 2FA, push notifications, or just plain emails or further challenges if something looks suspicious (e.g. logins from Africa when I'm also logged in from the US)
While I don't consider the notifications to be part of the authentication - I agree, yes, notifications are good.
We're doing something like that at my company as well (its not a bank or anything). If you log from other countries, have too many repeated failed (or even successful) attempts in a time period, etc. you get notified on a dashboard/you can optin for an email (or /and an email that forwards to your SMSes).
then you can decide if/when you want to see it and to notify security if you think there's a problem. saves a lot of time for the sec team as well which only will manually check when the alerts reach a higher threshold.
We're doing something like that at my company as well (its not a bank or anything). If you log from other countries, have too many repeated failed (or even successful) attempts in a time period, etc. you get notified on a dashboard/you can optin for an email (or /and an email that forwards to your SMSes).
then you can decide if/when you want to see it and to notify security if you think there's a problem. saves a lot of time for the sec team as well which only will manually check when the alerts reach a higher threshold.
That was bone-headed stupidity. RSA could easily have used more expensive HSM hardware, and the rest of us can spend a grand on two YubiHSMs or equivalent hardware. (Or trust Google's....)
There's little excuse to poor secret management if you run your own hardware.
There's little excuse to poor secret management if you run your own hardware.
> (Or trust Google's....)
What does that mean? Where do you need to trust Google's?
What does that mean? Where do you need to trust Google's?
I meant, "or trust Google's ability to keep their two factor authentication keys secret (with their Authenticator app)". Though perhaps I also meant using Google Authenticator app with your own keys ... except you'd still need to keep them somewhere, which means ideally an HSM and we're back to square one. :)
What do you mean by "their" two factor authentication keys? There are no "their" keys.
TOTP/HOTP is an open standard and Google Authenticator is an open source app. You can audit it, or write your own. It's not even that hard to implement.
TOTP/HOTP is an open standard and Google Authenticator is an open source app. You can audit it, or write your own. It's not even that hard to implement.
I'll chime in because theres a lot of mis-information here.
My credentials: I am the founder of Authy, we do two-factor authentication using SMS, Phone Calls, TOTP App and Hardware Tokens - we protect over 80,000 accounts including CloudFlare, Coinbase etc, so I am very familiar.
On 2FA using SMS:
1. Yes it's not as secure as a dedicated TOTP App but:
2. SMS phishing doesn't matter here. SMS phishing would allow the attacker to send message as you but not receive messages. In order to compromise Two-Factor SMS auth he would need to be able to receive them.
On VoiceMail Security:
1. True, voicemail is insecure. But if your Two-Factor Auth provider knows anything about security, he can help you. For instance we just helped Coinbase with Voice verification. In order to protect the verification codes going to VoiceMail, we require the person to input a number before reading the token.
Eg. Hello, this is Coinbase, if you are expecting this call, please press 1. [ Only on 1] your code is, “1,2,3,4,5,6,7”. Again “1,2,3,4,6,7”, last time “1234567”.!
So if you can only use SMS or Phone Call Two-Factor Authy, by all means use it. If you have a Smartphone it's better if you move onto a dedicated TOTP App.
The biggest weaknesses this days on Two-Factor Auth is not SMS or the carriers, it's the implementation. Unfortunately although implementing TOTP is easy, a secure Two-Factor system is not. Most are using recovery codes, e-mail and defective recovery mechanisms, which is how this systems are being by-passed.
http://www.slashgear.com/dropbox-hack-allows-bypass-of-two-f...
Find yourself a good Two-Factor Authentication provider. I would recommend Authy, but I am biased so I'll recommend Duo-Security.
My credentials: I am the founder of Authy, we do two-factor authentication using SMS, Phone Calls, TOTP App and Hardware Tokens - we protect over 80,000 accounts including CloudFlare, Coinbase etc, so I am very familiar.
On 2FA using SMS:
1. Yes it's not as secure as a dedicated TOTP App but:
2. SMS phishing doesn't matter here. SMS phishing would allow the attacker to send message as you but not receive messages. In order to compromise Two-Factor SMS auth he would need to be able to receive them.
On VoiceMail Security:
1. True, voicemail is insecure. But if your Two-Factor Auth provider knows anything about security, he can help you. For instance we just helped Coinbase with Voice verification. In order to protect the verification codes going to VoiceMail, we require the person to input a number before reading the token.
Eg. Hello, this is Coinbase, if you are expecting this call, please press 1. [ Only on 1] your code is, “1,2,3,4,5,6,7”. Again “1,2,3,4,6,7”, last time “1234567”.!
So if you can only use SMS or Phone Call Two-Factor Authy, by all means use it. If you have a Smartphone it's better if you move onto a dedicated TOTP App.
The biggest weaknesses this days on Two-Factor Auth is not SMS or the carriers, it's the implementation. Unfortunately although implementing TOTP is easy, a secure Two-Factor system is not. Most are using recovery codes, e-mail and defective recovery mechanisms, which is how this systems are being by-passed.
http://www.slashgear.com/dropbox-hack-allows-bypass-of-two-f...
Find yourself a good Two-Factor Authentication provider. I would recommend Authy, but I am biased so I'll recommend Duo-Security.
Good tip about the voicemail. Though in theory, with VOIP becoming more popular, it's still just a matter of time before more people run into the phone-call-redirect or even text-message-redirect if services like Google Voice pick up elsewhere. In addition, there's the social engineering hacks of last year, where the attackers added a credit card, then gained access by verifying that same card. At the end of the day, humans always play more of a role in security than people assume. Thanks for the tips, though! I'll revisit this thread later for 2FA.
My biggest problem with 2FA that relies on a phone is that I can lose my phone. If I do, the system can then do one of two things:
a) it locks me out forever. I'm screwed.
b) it has a way to reset my auth. Meaning an attacker doesn't actually need my phone.
So getting the phone involved is either a huge risk or a pointless feel-good factor that can be bypassed. Either way, I'm not on board.
a) it locks me out forever. I'm screwed.
b) it has a way to reset my auth. Meaning an attacker doesn't actually need my phone.
So getting the phone involved is either a huge risk or a pointless feel-good factor that can be bypassed. Either way, I'm not on board.
This is where one time codes that you keep in your wallet come in.
Many second factor auth systems use this. There is a list of 10 codes that can be used once each (and they're only valid used in order, so only one is valid at a time). You print this list out and keep it in your wallet or wherever else in case you lose your phone. If you lose both your phone and this list, then you are in fact screwed.
Many second factor auth systems use this. There is a list of 10 codes that can be used once each (and they're only valid used in order, so only one is valid at a time). You print this list out and keep it in your wallet or wherever else in case you lose your phone. If you lose both your phone and this list, then you are in fact screwed.
Two factor is something you know (but can forget) and something you have (and can loose). The risk is there, regardless of the thing you have being a phone or key fob or smart card.
Losing your phone is not the same as losing your phone number.
+1. And in a world of VoIP that can be both good and bad ;-) That said, if you use Google Authenticator, it's just a backup away. And you can add additional numbers, which again provides that tradeoff between security and convenience. At the end of the day, high value targets should be defended in depth, with least exposure to attacks and easily dropped if compromised. Which means maintaining inbox zero on servers others monitor but are less shared (so you can phone someone) and implementing login systems without failsafes. Of course, IMAP wasn't built for much of this 2FA stuff ;-)
This is an argument against using SMS or phone calls as the second factor, apps like Google Authenticator are still a really great option (as the article states).
Here's the story of a banking trojan attack that redirected the victim's phone to authenticate large transfers:
http://williamedwardscoder.tumblr.com/post/24949768311/i-kno...
Scary when it really happens.
(My blog post)
http://williamedwardscoder.tumblr.com/post/24949768311/i-kno...
Scary when it really happens.
(My blog post)
A problem for security geeks is they frequently forget about 2 things: 1) the balance between usability and security, and 2) The risk acceptance/appetite of the person for the security they want/need to use.
The two are intertwined closely. For something that isn't that important, a user isn't going to jump through complex hoops every time they have to login. What they will end up doing is finding workarounds (Hello Mr. Post-It).
For most folks, they don't really need complex solutions to reset their email password. What needs to be asked is "What am I protecting, and what is it worth to me?"
Oh, and I'd suggest certificate-based auth is way better than complex passwords.
Daniel's been around for a while (I've loved OSSEC for years) so I suspect this post just wasn't meant to be a complete essay on the topic...
The two are intertwined closely. For something that isn't that important, a user isn't going to jump through complex hoops every time they have to login. What they will end up doing is finding workarounds (Hello Mr. Post-It).
For most folks, they don't really need complex solutions to reset their email password. What needs to be asked is "What am I protecting, and what is it worth to me?"
Oh, and I'd suggest certificate-based auth is way better than complex passwords.
Daniel's been around for a while (I've loved OSSEC for years) so I suspect this post just wasn't meant to be a complete essay on the topic...
This was an easy choice for us when we setup two-factor auth for our app. We chose TOTP. The only real con (if you can call it that) is requiring the user to install a TOTP app (eg. Google Authenticator) but given our target userbase that was a non-issue.
Here's a quick summary of pros/cons:
TOTP pros:
[2]: Clock sync is really important. If you're going to do a TOTP implemenation make sure you run ntpd/ntpdate to keep your clock in sync.
Here's a quick summary of pros/cons:
TOTP pros:
* Assuming the initial secret is delivered securely (eg. HTTPS) no MITM vulnerability
* Free as in beer
* Simple to implement
* Instantaneous
* No additional personal information asked of user[1]
* Requires user's to install an app or have a physical TOTP device
* Clocks must be kept in sync[2]
* Nothing to install assuming your user has a phone
* Not free as in beer
* Could be MITM by telco or anyone with access to telco data (wireless scanner)
* Requires asking for the user's phone number
* SMS is *not* instant, could be minutes or more to receive a message
[2]: Clock sync is really important. If you're going to do a TOTP implemenation make sure you run ntpd/ntpdate to keep your clock in sync.
What about losing your device? How is that handled with something like Google Authenticator? Don't you then have to fall back to some sort of manual verification?
If you lose your SMS authenticated Phone, you can get a new one and transfer your number to it.
If you lose your SMS authenticated Phone, you can get a new one and transfer your number to it.
If you lose your device then you restore it from a backup. For Google apps's 2FA setup they also have one time use codes. It s a special list of 10 codes that you're supposed to save somewhere safe offline (eg. wallet, deposit box, trusted neighbor, ...). If you lose your device you can use one of the codes to login and configure (or disable) 2FA.
I've had backup restore to a new device not work for google authenticator (I assumed that was by design), which is what has made me wary of it.
But for your app, I assume you use manual re-authentication if someone loses their device?
But for your app, I assume you use manual re-authentication if someone loses their device?
I've upgraded my phone 3 times so far (3G -> 4 -> 4S -> 5) and no issues with migrating Google Authenticator settings. I do have the habit of wiping out all my music but that's because I never bothered to setup iTunes properly (plus my desktop is Linux so I run it in a Windows VM).
I'm not too worried about the restore not working as I have the single use codes securely saved as well (and tested). If I lost my phone or bricked it during an upgrade I can just use those to set things up again in ~15 minutes.
I consider that process superior to waiting to get a new phone. More importantly on a day to day basis (eg the normal case where you don't lose your phone) it's more secure as it can't be MITM without getting the TOTP secret either from my phone or from the system I'm authenticating against.
I'm not too worried about the restore not working as I have the single use codes securely saved as well (and tested). If I lost my phone or bricked it during an upgrade I can just use those to set things up again in ~15 minutes.
I consider that process superior to waiting to get a new phone. More importantly on a day to day basis (eg the normal case where you don't lose your phone) it's more secure as it can't be MITM without getting the TOTP secret either from my phone or from the system I'm authenticating against.
He gives an example of what can happen with voice-based authentication but not SMS. What can an attacker do, collect the text as it passes between the cell tower and your phone then use it before you get the chance to?
Or is it the scenario where they've stolen your password and your phone? If it's a smartphone, they'd have to be able to unlock it and once they've done that, SMS doesn't seem any worse than Google Authenticator.
Or is it the scenario where they've stolen your password and your phone? If it's a smartphone, they'd have to be able to unlock it and once they've done that, SMS doesn't seem any worse than Google Authenticator.
Number porting attacks have been used to compromise SMS-based auth in the past.
http://www.itnews.com.au/News/282221,phone-porting-used-to-u...
http://www.itnews.com.au/News/282221,phone-porting-used-to-u...
If you could social engineer an employee to change a voicemail number, you may be able to convince them to port a number to a new account.
There have been bank account hacks where the perpetrator has had an accomplice inside a cellular service provider who intercepted the SMS and prevented it from being sent to the account-holder's phone while retrieving the code.
"And please remember 2FA is not a substitute for a good password policy."
2FA is not a replacement no. What it does is increasing security in environments where you might risk that your main password is compromised.
This doesn't mean you are free to reuse passwords but it still significantly raises the bar for a successful attack.
2FA is not a replacement no. What it does is increasing security in environments where you might risk that your main password is compromised.
This doesn't mean you are free to reuse passwords but it still significantly raises the bar for a successful attack.
I can't help but think maybe this is similar to having only the login screen https, but the rest of the site http with the auth cookie being passed around in clear text... Initially, we thought we were being more secure because we secured the transfer of the password to the website, but in reality the auth cookie is just as important.
In the case of typical 2 factor authentication via phone - if I can reset your password via a code being sent to your phone, then you've lowered the security of your password from maybe an 8 digit password to a 4 digit numeric pin...
Of course, I would need to know your phone number, which may be difficult to guess?
In the case of typical 2 factor authentication via phone - if I can reset your password via a code being sent to your phone, then you've lowered the security of your password from maybe an 8 digit password to a 4 digit numeric pin...
Of course, I would need to know your phone number, which may be difficult to guess?
Basic 2 factor authentication doesn't even cover the scope of password resets, so the idea that 2FA is flawed when used in conjunction with cellular networks is a terribly unthought out argument. If any service uses a token reset code sent to a phone as SMS or voice message, then that service is using a flawed password reset mechanism using the idea that cellular networks are highly insecure, regardless if it's also using 2FA. _Any_ single authentication mechanism over cellular networks is flawed using the same logic. 2FA, arguably, is more secure over cellular networks because it requires an authentication mechanism (the password) that is not transmitted over SMS/voice cellular in a plain format (assuming the authentication itself is sent over TLS/SSL).
great points, clearly i was misunderstanding, the reset mechanics i was describing are clearly a very bad idea and not 2 factor. thanks!
Is there a problem with a system whereby a business already has clients phone numbers and uses them to send the client a temporary PIN when the client enters their phone number as a username on the business's website?
Yes: call/SMS forwarding. It depends on how good your first factor (e.g. password policies) are, and how your reset process works. Getting someone's phone number and setting up call forwarding doesn't require much social engineering savvy to pull off.
http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
Call forwarding doesn't forward SMS. I don't think you can do SMS forwarding (at least for any carrier I'm aware of). You'd need to social engineer the carrier to port your target's number to a different phone -- in which case the target is going to be exposed to a ton of trouble...
that is how liqpay.com works. you enter number, receive one time PIN via sms to login
Easy to phish. If you know some basic information about the person, you can get the PIN changed.
That's not what phish means. Phishing in this case would mean the victim gives you her PIN, assuming you are trustworthy.
That's not what phish means. Phishing in this case would mean the victim gives you her PIN, assuming you are trustworthy.
I'm not sure phishing is limited to situations where you attack the account owner, though I could be wrong. Going off of the Wikipedia entry (though this doesn't prove anything either):
> Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.
https://en.wikipedia.org/wiki/Phishing
> Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.
https://en.wikipedia.org/wiki/Phishing
I don't really understand the argument the author makes about SMS being easy to spoof. Most of the 2FA systems I've seen using SMS use it to communicate a secret that the user needs to type back in on whatever screen they were at. If an attacker spoofs the SMS message, the user is just going to get some secret that doesn't work when they type it in.
I"ll just go ahead and remind that many people use google authenticator to authenticate accounts ON THE SAME PHONE.
It's dumb, inconvenient, but yeh.
Security is about systems, not individual components. Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account. The number of attackers that will be able to attack your login page and intercept SMS's for a specific user within the phone network is limited to three letter agencies.
The best security is security that people will actually use. Virtually everyone has a mobile phone and thus why the SMS channel is attractive.
Sure, this isn't the be all and end all in security and an app like Google Authenticator is more secure but SMS as a second factor is ideal for most consumer applications.