SMS logins: an illusion of security | Hacker News Reader

SMS logins: an illusion of security

danielpocock.com

64 pointsbkor17 comments

I think this article is blatantly missing the point. Adding two-factor auth is the best way to stop shared compromised credentials (we all know people who don't use a random password everywhere) being reused on every common login form on the internet. Companies like Facebook are not going to issue everyone with authenticated tokens or smart cards. SMS though being a simple hurdle for a determined hacker it is effective at stopping en masse attacks on compromised credentials.

Using SMS as two factor auth for a bank does seem stupid to me as I expect hackers to be more determined to crack my bank account than my Facebook account. Banks have the resources and the long account setup times to allow them to use proper auth tokens.

Is there a better solution that SMS for low risk sites like Facebook or Twitter or my blog etc? Something with the same easy of use portability etc. Is the Google Auth token app any better?

EDIT: login not logic in first paragraph

I think it's important to distinguish between the use of SMS in two-factor authentication vs. single-factor. The author is referring to single-factor authentication in the form of SMS one-time passwords. He has some great points, but I don't think they discredit the effectiveness of SMS as a component of two-factor authentication.

Discrediting the security of SMS tokens applies whether or not they're a single factor or part of a multi-factor system. If logging in to my account requires a password and an SMS token, and SMS tokens are so easily compromised, my account is effectively protected by only a password. While compromising the token alone doesn't give an attacker access to my account, I can't consider my account to be protected by multiple factors.

There are many sites that will use sms tokens as a recovery option as well. Making them a singular point of compromise even in a two-factor system.

Multiple factors help a lot even if most of the factors a not very secure, because now the attacker has to compromise both of them for the same target in order to succeed. So if a bank uses SMS and a password you need to develop a way to capture passwords and then also capture SMS messages. The number of accounts you compromise is the intersection of these two sets, instead of the union which would occur from two separate exploits. So it increases the costs of attackers significantly.

Of course a properly cryptographically secure token is better (and you should demand such for important stuff like access to your bank account), but SMS as a second factor is far from useless.

EDIT: SMS also has the property that compromise is transient: not only do you have to compromise two seperate systems, but you need to compromise one of them at the time which you wish to login.

SMS security tokens have significant weaknesses; yes. The reason for multi-factor authentication is to compensate for the weaknesses of any single factor. This works reasonably well as long as the factors aren't so weak as to be trivially surmounted.

If there existed a single authentication factor that was at once practical and perfectly secure, then there would be no need for multi-factor auth.

The point of the article is that SMS as a security factor is weak enough as to be trivially surmounted.

Weak, yes. But trivial? The article does not convince me of that.

> In this context, the telephone network itself may no longer be the weakest link in the chain. The diligent attacker only needs to look for the cloud operator with an unplugged security hole and use their system as a stepping stone to read any SMS they want, when they want.

This is the most practical attack described in the article. Attack vectors like this will occasionally open up, but I would not call it trivial.

I agree. That quote basically describes any technical attack on a service. You could write any article stating XYZ tech is insecure if you're sounding the alarm based on "future unknown vulnerabilities".

Since the original link seems to be down: https://webcache.googleusercontent.com/search?q=cache:daniel...

While I don't strongly disagree with any of the points made regarding the security of the SMS network, I do feel that the article is inordinately preoccupied with banking, and dismisses SMS authentication out of hand because it isn't good enough for your bank. In the case of a bank, I agree that a security token certainly is the right tool for the job. But what about other login services?

It doesn't really matter to me, as a developer, whether SMS is impregnable. It matters whether it is harder to break than user-originated passwords. Users are notoriously bad at picking good passwords, and are easily socially engineered.

We can implement password policies to attempt to mitigate this, but what we end up doing is frustrating our users, who will struggle to remember the 8 character minimum, alphanumeric, at least one capital letter, at least one piece of punctuation password we have forced them to choose.

What ends up happening is that users either forget their "strong" passwords, and have to reset them via email or SMS every time. Or they write their passwords down or store them all on a spreadsheet. Or they reuse then same strong password across multiple services (and even correct horse battery staple doesn't avoid that one).

SMS authentication may not be perfect, but single-use passwords, with nothing for the user to remember, is an improvement on weak user-originated passwords. For my money, at least!

    >>> math.log((26+26+10+32) ** 8, 2)
    52.4367108134211

So a "perfect" 8-character password has about 52 bits entropy.

    $ wc -l /usr/share/dict/american-english
    99171 /usr/share/dict/american-english

    >>> math.log(99171,2) * 3
    49.792892048685374

3 random dictionary words has almost 50 bits. 4 words would have about 66 bits.

Couldn't average-user password strength be hugely improved by giving better password instructions (if your signup / passwork-change page is SSL as it should be, maybe even provide a few dozen random words as possibilities)?

> dismisses SMS authentication out of hand because it isn't good enough for your bank.

My bank seem too have decided that it's good enough.

Ha! I work with banks every day and see some of the worst architectural decisions made in the name of security. What's worse is most of these decisions actually make their systems less secure!

It seems to be impossible for banks to NOT role their own authentication systems. And every one I've seen ends up with passwords stored or transferred in a way less secure than if they just plugged in an OAuth library or use any of the standard WSS/WSSE options to secure their SOAP endpoints.

Why aren't smart cards more popular? Is there even an API for web pages to make use of smart cards (I'm not a web developer)? I know yubikey, but I do not understand the concept. A simple smart card token should be sufficient (like the yubikey NEO). I do not own a smart phone, but it would make sense to have smart cards built in, register your phone's public key to your service and use a challenge-response like authentication for second factor.

It's a price and usability problem.

The basic functionality (SSL Client Certificates) is built in to all major browsers and servers. Enabling it up takes only a few hours and doesn't require any third-party software or hardware at all.

Actually getting your users to buy a smart card reader, find a card that has drivers for their browser/OS combination, buy that card, and spend half an hour setting it all up? Good luck with that.

Relevant to the topic: a map of the state of GSM insecurity:

http://gsmmap.org/

Reply on news.ycombinator.com