11

Twitter released(some time ago) a new kit named Digits which allows the client to login with a phone number and an authorization code (received through sms). I find it great for the user experience and I was thinking to implement it on our app/website too but isn't this "very" insecure? I can imagine several issues:

  • the phone number is easy to guess: This allows the attacker to run successful blind SPAM campaigns even location-based(state, city based on the prefix). If most of the internet users would use phone numbers instead of email addresses I'm sure the amount of spam they receive would be higher. The spammers won't need to worry about email addresses harvesting. They would just generate phone numbers with a good chance to catch valid/active ones.
  • the sms is insecure: Unlike the email service the SMS has no authentication protocol(as far as I know) such DKIM, SPF so even experienced clients are unable to verify the integrity of the sender(i.e. if it's twitter or a spoofed number). Once you register/authenticate with the phone number you also establish SMS as communication channel. So it's not only the authentication code that you receive through sms but all the communications (confirmations or whatever twitter sends) are are sent though a channel which doesn't support authentication. This is basically like email without DKIM, SPF and even without any SPAM filter.
  • disturbance: brute forces most of the the valid phone numbers just for fun to generate disturbance(i.e. make twitter send auth codes to all the possible phone numbers). There may be sensible IP restrictions but I can't see this stopping the attacker.
  • data harvesting -> malware: The attacker finds what phone numbers are registered on twitter(see brute-force), sends them SMS (which looks like a twitter notification) with malicious links.
  • phishing: the client may be more willing to disclose a code received through sms than a password. If a phishing form is asking for a sms received from twitter(MITM) I think the client is more willing to provide it than a password as the code is received on request (not expected to be a secret the client is remembering) and the process( wait for the SMS and copy/paste it) distracts the client from the login page. It's also worth to note that the SMS notification covers the header of the UI(address bar). enter image description here

enter image description here

8

Digits leverages a single 'factor' typically used in multi-factor authentication: "something you have", which in this case is your phone. Yes, there are weaknesses in the security of a single factor, just like only using a password, but there are strengths over and above a simple password, too.

  • disturbance - yes, an attacker could spam the phone network, but that in and of itself does not reduce the security of the process. It might create a DoS scenario depending on how Digits is design in the backend.
  • data harvesting -> malware - I tried the demo with a phone that is not registered with Twitter and it worked. I don't see this as a valid way to discover registered Twitter users for targeted phishing, no more than blanket spam does.
  • data harvesting -> phishing - As a phishing researcher, I could imagine this could be true. But I'm not sure if a user would realistically be more susceptible to phishing in this way than any other type of phishing for passwords. I don't think I understand your threat scenario here.
  • the sms is insecure - yes, SMS is not a secure channel, just like email, but you get a code when you have triggered the code to be sent. I'm not sure that one would receive a gratuitous code and start hunting around for an app they didn't log into for the purposes of entering it. As for MITM, the same protections of the website apply for certs, DNS, etc. and the threats would be common for password-based logins.

Given your risk model, I'm not sure that Digits is less secure than a password at all. It is a challenge-response mechanism using a phone as a factor. Protections of the login page and the personal protections of the phone (locks, encryption, remote management) can all be employed by the user to possibly make this more secure than a typical password mechanism. Yes, it is still a single factor, and yes there are ways for a user to make this insecure, but the mechanism itself is not inherently insecure.

  • 1
    I think the question was a bit badly formatted. The issue is more about using a phone number/sms instead of an email address as communication channel not only during the authentication flow but also after that. As digits encourages the use of sms instead of email the resource owner is supposed to use the phone number as communication channel too. There is also the DoS scenario which I find quite hard to mitigate because the attacker can provide valid data (phone numbers). – themihai Apr 29 '15 at 16:03
  • 1) I'm not sure I understand your risk analysis for spam - how would an attacker validate the phone number? 2) As for using SMS for all communications, that does not weaken that channel for authentication. 3) I'm not sure the MITM phishing page would be any more successful with a SMS code than a password (successful MITM could be impossible to detect either way). 4) SMS notifications are configurable and do not necessarily cover the UI bar (and that doesn't apply for desktop sites). – schroeder Apr 29 '15 at 17:04
  • 1) In the worst case scenario the attacker would just generate the phone numbers with no validation in place. With a good algorithm you can get valid phone numbers on specific locations (i.e. state). – themihai Apr 29 '15 at 19:20
  • 2) The more exposed you are the weaker is the security of your system. In this case the auth flow itself increases the attack surface due the predictability of the phone number. It seems to me that you don't consider the security of the system as result of a such authentication flow. Maybe I'm missing something but if the authentication flow is considered alone then regardless communication method (SMS, email, carrier pigeon or whatever) an OTP(One time password) is just an OTP. – themihai Apr 29 '15 at 19:22
  • 1) I get that it is trivial to generate phone numbers, but I'm not sure what the threat is here for the user. They will get a gratuitous SMS with a code, and the user will have no idea which site triggered it. – schroeder Apr 29 '15 at 19:22
1

According to this article on Wired, it is.

https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/

The attack: "... The hackers, as he tells it, had called up Verizon, impersonated him, and convinced the company to redirect his text messages to a different SIM card, intercepting his one-time login codes."

0

Yes, it is insecure, in addition to violating your user's privacy.

This solution gives Twitter, the mobile carrier of the user and the various governments of the countries where Twitter and the aforementioned carrier have business the ability to impersonate your users on your platform without them noticing. To make it more clear : any rogue employee or attacker inside Twitter or the user's carrier can log in as any of your users.

And as if it wasn't bad enough already, this makes Twitter aware of the times and locations (IP, user-agent, any browser metadata) from where your users log in, so Twitter can now correlate these info to build a profile of the user, on what sites does he log on, at what times, and whether he has a Twitter account (based on cookies since they control both the Digits domain and the normal Twitter domain) so they can pollute his timeline with sponsored tweets based on the info they now know about the user.

Finally, asking users their phone number is not a good idea if you want users to sign up on your site - as a tech-savvy user I wouldn't give it out for the reasons mentioned above, but most less tech-savvy users would still refuse to do so just to avoid potential SMS spam.

  • I think that privacy is a side issue to the OP's question. You don't address the authentication security of the scheme. You are also making some wild assumptions about why the downvoter acted. – schroeder Apr 29 '15 at 17:07
  • @schroeder I clarified the bit about authentication. Deleted my other comment which was a bit harsh, though I'm pretty sure I got the downvote reason right. – user42178 Apr 29 '15 at 18:01
0

Here are two more issues to add to the list:

  1. Start a digits auth on your device against your target's phone number. Then shoulder surf your target to get the auth code from their phone's lock screen (use your device to take a picture of the target device if necessary). Enter the code on your device and you are in the target's account.

  2. Since it is locked to the mobile device by SMS, only the device owner can ever log into the application from that device. If the owner allows someone to borrow their device to access that other person's own data (like you would a web browser to check your mail on someone else's device), the obvious way of authenticating (using the number of the mobile device in your hand) will result in inadvertent access to the device owner's account.

  • It doesn't make sense. If the attacker has access to your device it's all lost sooner or later regardless the authentication method. – themihai Jun 6 '15 at 20:49
  • 1. doesn't require physical access to the device itself - it's shoulder surfing. 2. is not claiming to be a vulnerability of the type you are saying it is not. It's just another reason I wouldn't recommend using it. – David K. Hess Jun 8 '15 at 0:45
  • The point #2 says something about borrowing the device. – themihai Jun 8 '15 at 0:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.