If you’re reading this, you probably peeped that moment when @deray’s account tweeted out how he was allegedly supporting Donald Trump . Deray responded after deleting said tweet:
Whenever something happens on the Internet, people tend to write about it. Like Wired or Buzzfeed. Buzzfeed was useful here and did homework on the big four telcom providers in the US on informing you how to prevent people from overriding your account. But this shows a problem in the pipeline.
Before we continue, I’ll define a few terms.
- telcom is short for telecommunications community. This is T-Mobile, Sprint, etc.
- 2FA is short for two-factor authentication. It’s like that extra lock on your door. Except that it shouldn’t be the same kind of lock you’d typically to open your door. More on that later.
- OTP is short for one-time passwords.
- TLS is the successor of SSL, what provides security for HTTP on the web. It’s indicated to be in use and active if you see a green lock in your address bar.
There’s a lot of abbreviations in the security space. A little too many.
We still have to remember a code that’s sent over the phone (or given to us in person) that’s hopefully hashed on the telcom’s side and now stored insecurely (if it’s not encrypted somewhere, you ain’t keeping it safe, b) by the consumer. This still doesn’t address the fact that SMS is very weak in terms of message security with the correct tooling.
If You Can’t See It, Chances Are You Can’t Control It
When it comes to SMS 2FA, social engineering is the way to break it. The FTC’s CTO got compromised this way as well! The most commonly suggested way for users (note - not even the company) by telcom providers to handle this is to use yet another password or PIN1 to protect your account. This is more that you have to remember and more risk external entities that you have to trust are offloading to you.
Here come the secure tokens. A secure token is a device or an abstraction of one that can provide the following (and more):
- generates a OTP for the sake of a login or authorization window.
- generates a signed message with a stored private key.
- presents a challenge and valid response for authorization.
One time passwords can also be sent via SMS, but for the simple reason that you aren’t the origin of generation of said one-time password and that it’s transmitted over an insecure protocol (a pre-established means of sending and receiving data); you’re extremely liable to get comprised by a social engineering attack like the one that happened to Deray and the FTC’s CTO.
Having these secret generators local to your person makes it harder for social engineering attacks that rely on external companies. Of course, there’s other vectors people can attack you from:
- insecure networks could attempt to strip TLS (or masquerade as a site that wants you to use your OTP), capture your OTP that you’ve entered and login on your behalf. Side-note: do NOT login or handle sensitive information over open/insecure networks or networks you don’t fully control or trust2.
- idleness of your machine could leave someone momentarily sniffing your keystores via a USB device that transmits your keystores out to their machine and even a screenshot of your device3.
- physical (written) recording of backup codes generated by OTP solutions that use secure tokens. One of these codes can pull down the entire house.
Recapping SMS Spoofing and How SMS 2FA Typically Works
SMS spoofing is the act of sending a message from one number to a victim’s phone as another number, a form of masquerading messaging. This could allow an attacker to emulate a request from a service to provide a OTP backup code or password. With that, they can enter said service (let’s say it’s GMail) and work as if they’re you4.
Currently, with SMS-based 2FA (I’m calling this SMS-FA), you have to depend on a remote service to generate a nonce, a uniquely generated value that should be computable at most once on request. Ideally. You then wait for said nonce to travel over SMS from a third-party service (like Twilio or Tropo) to your phone. This means the only person who can confirm that this number is truly the value to be checked for authentication is the remote party. You have no way to know for sure that this is a valid value to be used here nor can you be sure that the value computed hasn’t been used already - it passes through two different people before it gets to you.
Google supports the use of secure tokens as well as bunch of websites that you may find on https://twofactorauth.org/. The key thing here is to look for hardware token support. If your preferred service doesn’t have it and you’re extremely concerned about security, you might want to switch or suggest another tool to said company.
There’s also the idea of using email for authentication. For a lower barrier means of getting into this, using emails to sign in remotely can help. A lot of services like Slack and Medium currently provide this as an option.
Why Do Secure Tokens Matter so Much?
Secure tokens provide a very interesting approach to logging into a service. Instead of you constantly typing a passphrase to a service over and over again, the remote service and the secure token go through a bit of a negotiation phase.
On first setup, the device would share a public key or a pre-shared key that both the device and the remote service are aware of. This public key is what’s going to be used by the remote service to ensure that the message sent is from who they think it is and how the device can prove that its personal key from which the public key is derived from is legit.
This is important (the whole sharing of a public key - PSK) so that whenever the secure token generates a signed message that’s meant to hold information that was intended only for the service in question; you, as the remote service, can confirm that the message you intended to send out was indeed from the party in question.
Still with me? Awesome . Now, let’s see some definite wins for using secure tokens over SMS as an 2FA (or a primary factor) option.
You can destroy them.
The minute you feel that your account’s been compromised or if you need to shake off a commonly used device, the destruction of your security token and having at least one trusted device to log in from allows you to sweep your authentication cycle.
There is a hole here and it’s an unsolved tactic of this whole process: recovery. If you lose your token or can’t access any previously trusted devices, how do you get in? Ideally, you shouldn’t be able to: this is the same situation an attacker would be in. However, in the case of one-time passwords, you’re issued a set of codes that can be used as valid (but momentarily, since you can only use them once) codes for signing in. Keeping these numbers secure is crucial since they effectively break the whole flow for one-time passwords5.
MITM (Man In the Middle) attacks become nigh-impossible.
Since the act of generating a secure, valid and confirmable value is now delegated to a secure token you own, you can now send this value directly to the asking party and not have to concern yourself with the number of hands this sensitive value had to travel to get to you.
You, as a user, need to remember nothing.
Customers of a service, or users of a service in general, now have to remember nothing at all. In the case of people using their personal devices like a laptop or phone as an authenticating factor, the only thing they’d probably need is the system’s password or PIN. In the case of most consumer applications, this tends to be well more guarded than someone’s password to Netflix.
No more sharing of passwords.
Without the use of passwords and relying solely on pre-shared keys for authentication and authorization, we now don’t have to worry about users recycling passwords to use across different sites.
There is the issue of a public key being shared across multiple services though. This is something Clef manages to mitigate with unique logins across different applications you interact.
Again, this pushes a lot of the act of handling recovery, remembering and storage fluff onto the user. There’s also the now shared key across all of these services if a user is afraid of having their key seized.
If you’re a developer at a company and you’re serious about making it easier for people to sign in without any concerns (or passwords), check out Clef6. Clef’s building two factor products that handles a lot of the work for both the company to be secured and the user handling their credentials. Recovery of accounts comes with this service. Check out how Clef works and see how classical attempts at user authentication can be protected using Clef.
It’s also on this premise here that I suggest Clef as an answer:
Passwords are the zombies of user security. They should be dead, but due to a myriad of reasons (low prioritizing as a concern by companies, users finding alternative options as too high a barrier or confusing, etc), they’ve managed to stick around. We, as developers and consumers, can fix that and prevent social engineering attacks based on leaky implementations of 2FA from happening.
What Can You Do?
I threw a lot of terms and random tweets in your face just now. What I can immediately suggest is not that you disable any SMS factor of one-time passwords for services. Instead, inspect what services you currently have secured via SMS 2FA and switch them over to using a software-implementation of this (dubbed TOTP). There’s a few implementations of this - I lean on open implementations purely for the ease of mind to know that the underlying secret used for this isn’t being shared with a third party. There’s FreeOTP for Android and iOS.
OTP applications are a bit of a stop-gap. Microsoft has a compelling solution that makes even signing in on the Xbox One4 easier: Microsoft Account. Instead of relying on SMS, Microsoft went ahead and built an in-house solution that handles login verifications. Microsoft isn’t the only one with this; Twitter had this as an option for their mobile clients7, but removed the push notification approach with the SMS solution. How comforting.
I say all to say that security, just the authentication of identity part, isn’t easy but there’s people and actively working solutions out there already. I’m working at a place that’s aiming to make it a lot easier for people to prove who they are online and hope that future conversations can lead to a better experience for both services and users.
Usually 4 digits, to be used as a “barrier of protection”. ↩
This is that Starbucks WiFi or that protected network at your local coffee shop. ↩
Don’t leave your computer alone in a public place. Don’t trust people to watch it for you. ↩
One would notice that this means that all one would have to do is constantly try numbers until they get passed this flow. However, this typically requires knowledge of the user’s password. ↩
Yes, I work for Clef. ↩
The plot thickens! This could have potentially prevented Deray’s incident had Twitter disabled SMS 2FA when you had this enabled. ↩