Using Phones/SMS as 2FA – Why I am not a believer

This is utter stupidity. Somehow voicemail PIN weaknesses translate to being able to intercept SMS&#x27;s?<p>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&#x27;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&#x27;s for a specific user within the phone network is limited to three letter agencies.<p>The best security is security that people will actually use. Virtually everyone has a mobile phone and thus why the SMS channel is attractive.<p>Sure, this isn&#x27;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.

&quot;No 2FA. If the only option available is SMS or call-based authentication, do not use 2FA.&quot;<p>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 &amp;&amp; operation, not an || operation, for all modes of authentication. Otherwise, you are exactly right, and attackers will compromise the weakest link in the chain.

<p><pre><code> If you have the option to use RSA SecurID or Gemalto devices (used by Amazon), use them first. </code></pre> RSA SecurID was famously compromised back in 2011: <a href="http://en.wikipedia.org/wiki/SecureID#March_2011_system_compromise" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SecureID#March_2011_system_comp...</a><p>Any system where the manufacturer has a copy of the secret key on the token is theoretically vulnerable to this attack.

I&#x27;ll chime in because theres a lot of mis-information here.<p>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.<p>On 2FA using SMS:<p>1. Yes it&#x27;s not as secure as a dedicated TOTP App but:<p>2. SMS phishing doesn&#x27;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.<p>On VoiceMail Security:<p>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.<p>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”.!<p>So if you can only use SMS or Phone Call Two-Factor Authy, by all means use it. If you have a Smartphone it&#x27;s better if you move onto a dedicated TOTP App.<p>The biggest weaknesses this days on Two-Factor Auth is not SMS or the carriers, it&#x27;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.<p><a href="http://www.slashgear.com/dropbox-hack-allows-bypass-of-two-factor-authentication-05289228/" rel="nofollow">http:&#x2F;&#x2F;www.slashgear.com&#x2F;dropbox-hack-allows-bypass-of-two-f...</a><p>Find yourself a good Two-Factor Authentication provider. I would recommend Authy, but I am biased so I&#x27;ll recommend Duo-Security.

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:<p>a) it locks me out forever. I&#x27;m screwed.<p>b) it has a way to reset my auth. Meaning an attacker doesn&#x27;t actually need my phone.<p>So getting the phone involved is either a huge risk or a pointless feel-good factor that can be bypassed. Either way, I&#x27;m not on board.

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&#x27;s the story of a banking trojan attack that redirected the victim&#x27;s phone to authenticate large transfers:<p><a href="http://williamedwardscoder.tumblr.com/post/24949768311/i-know-someone-whose-2-factor-phone-authentication-was-hacked" rel="nofollow">http:&#x2F;&#x2F;williamedwardscoder.tumblr.com&#x2F;post&#x2F;24949768311&#x2F;i-kno...</a><p>Scary when it really happens.<p>(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&#x2F;appetite of the person for the security they want&#x2F;need to use.<p>The two are intertwined closely. For something that isn&#x27;t that important, a user isn&#x27;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).<p>For most folks, they don&#x27;t really need complex solutions to reset their email password. What needs to be asked is &quot;What am I protecting, and what is it worth to me?&quot;<p>Oh, and I&#x27;d suggest certificate-based auth is way better than complex passwords.<p>Daniel&#x27;s been around for a while (I&#x27;ve loved OSSEC for years) so I suspect this post just wasn&#x27;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.<p>Here&#x27;s a quick summary of pros&#x2F;cons:<p>TOTP pros:<p><pre><code> * 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] </code></pre> TOTP Cons:<p><pre><code> * Requires user&#x27;s to install an app or have a physical TOTP device * Clocks must be kept in sync[2] </code></pre> Phone SMS pros:<p><pre><code> * Nothing to install assuming your user has a phone </code></pre> Phone&#x2F;SMS cons:<p><pre><code> * Not free as in beer * Could be MITM by telco or anyone with access to telco data (wireless scanner) * Requires asking for the user&#x27;s phone number * SMS is *not* instant, could be minutes or more to receive a message </code></pre> [1]: I don&#x27;t like giving out my phone number and I assume most other people are like that as well. Less is more when it comes to sharing personal info.<p>[2]: Clock sync is really important. If you&#x27;re going to do a TOTP implemenation make sure you run ntpd&#x2F;ntpdate to keep your clock in sync.

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?<p>Or is it the scenario where they&#x27;ve stolen your password and your phone? If it&#x27;s a smartphone, they&#x27;d have to be able to unlock it and once they&#x27;ve done that, SMS doesn&#x27;t seem any worse than Google Authenticator.

&quot;And please remember 2FA is not a substitute for a good password policy.&quot;<p>2FA is not a replacement no. What it does is increasing security in environments where you might risk that your main password is compromised.<p>This doesn&#x27;t mean you are free to reuse passwords but it still significantly raises the bar for a successful attack.

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&#x27;s website?

<i>Easy to phish. If you know some basic information about the person, you can get the PIN changed.</i><p>That&#x27;s not what <i>phish</i> means. Phishing in this case would mean the victim gives you her PIN, assuming you are trustworthy.

I don&#x27;t really understand the argument the author makes about SMS being easy to spoof. Most of the 2FA systems I&#x27;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&#x27;t work when they type it in.

I&quot;ll just go ahead and remind that many people use google authenticator to authenticate accounts ON THE SAME PHONE. It&#x27;s dumb, inconvenient, but yeh.