

Using Phones/SMS as 2FA – Why I am not a believer - daviddede
http://dcid.me/notes/2013-apr-19.html

======
poutine
This is utter stupidity. Somehow voicemail PIN weaknesses translate to being
able to intercept SMS's?

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.

~~~
pfraze
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.

~~~
poutine
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?

~~~
pfraze
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.

~~~
pyre
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.

------
benmanns
"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.

~~~
michaelmior
Agreed. If BOTH are required than even if the second factor is relatively
weak, it's still better than password-only.

~~~
poutine
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).

------
danielpal
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...](http://www.slashgear.com/dropbox-hack-allows-bypass-of-two-factor-
authentication-05289228/)

Find yourself a good Two-Factor Authentication provider. I would recommend
Authy, but I am biased so I'll recommend Duo-Security.

~~~
lstamour
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.

------
sbierwagen

      If you have the option to use RSA SecurID or Gemalto 
      devices (used by Amazon), use them first.
    

RSA SecurID was famously compromised back in 2011:
[http://en.wikipedia.org/wiki/SecureID#March_2011_system_comp...](http://en.wikipedia.org/wiki/SecureID#March_2011_system_compromise)

Any system where the manufacturer has a copy of the secret key on the token is
theoretically vulnerable to this attack.

~~~
zobzu
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.

~~~
lstamour
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)

~~~
zobzu
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.

------
seldo
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.

~~~
rimantas
Losing your phone is not the same as losing your phone number.

~~~
lstamour
+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 ;-)

------
brown9-2
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).

------
willvarfar
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...](http://williamedwardscoder.tumblr.com/post/24949768311/i-know-
someone-whose-2-factor-phone-authentication-was-hacked)

Scary when it really happens.

(My blog post)

------
jlkinsel
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...

------
sehrope
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:

    
    
        * 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]
    

TOTP Cons:

    
    
        * Requires user's to install an app or have a physical TOTP device
        * Clocks must be kept in sync[2]
    

Phone SMS pros:

    
    
        * Nothing to install assuming your user has a phone
    

Phone/SMS cons:

    
    
        * 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
    

[1]: I don'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.

[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.

~~~
arn
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.

~~~
sehrope
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.

~~~
arn
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?

~~~
sehrope
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.

------
extra88
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.

~~~
benmanns
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.

~~~
_djo_
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.

------
eitland
"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.

~~~
taf2
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?

~~~
uxp
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).

~~~
taf2
great points, clearly i was misunderstanding, the reset mechanics i was
describing are clearly a very bad idea and not 2 factor. thanks!

------
tantalor
_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.

~~~
pfraze
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](https://en.wikipedia.org/wiki/Phishing)

------
cranefly
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?

~~~
_phred
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-honan-
hacking/)

~~~
poutine
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...

------
swampthing
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.

------
zobzu
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.

