Web Based OAuth Is A Security Nightmare For Apps


Twitter have just released Periscope for Android. I'll do a full review of it later (tl;dr it's Qik with worse resolution) - but for now, I want to focus on the sign up process.

You can only sign in with Twitter. That's fine, it's a Twitter product. So I pressed the sign-in button and this is the screen I saw.

Periscope Twitter Sign In-fs8

Is that the Twitter mobile website embedded into the app or is it a phishing page? I've no way of knowing!

I can't see the URL bar - for all I know, this could be an elaborate forgery. I have to completely trust that this product is actually provided by Twitter. In Periscope's case, it probably is. But this is teaching users a dangerous anti-pattern that the web community has tried so hard to eradicate. And, no, 2FA doesn't really help us here.

Let's take a step back and look at what the problem is.

In the bad old days, if you downloaded a 3rd party app (for Twitter, Facebook, email, etc) the app would ask you for your username and password. This is dangerous. You have no idea what the app is doing with your password. Is it saving it? Selling it to criminals? Silently changing all your settings? Who knows!

So, we introduce a more secure way of doing things, at the cost of a little more complexity.

OAuth

Here's how OAuth works (from a user's point of view - there's a lot more stuff going on in the background!)

  1. Click "Log in with Twitter" (or whichever service)
  2. Get taken to Twitter's website.
  3. Login (if you're not already).
  4. Get redirected back to the app
    1. Ideally the redirect automatically logs you in.
    2. In some circumstances Twitter gives you a PIN and says "Type this in to the app"

With OAuth you never need to give up your password to a random app.

It can be slightly cumbersome - especially if you have to remember a 4 digit PIN to complete the login. But I'm strongly in favour of educating users not to give out their passwords willy-nilly.

In Periscope's case, the user has to trust that the app hasn't just ripped-off the Twitter website. There's absolutely no way to verify that it is a genuine and secure login page.

Even if you have 2-Factor Authentication (where Twitter texts you a login code) you're not safe. Why? Because if the app is intercepting your username and password, it can also intercept your 2FA code. Sure, it can only use it for a minute or so (with some restrictions) - but that's enough time to completely take over your account.

As software developers, we have to stop encouraging this anti-pattern. Periscope is teaching users that it's OK to type their password into any box which looks like it's authentic.

Some Solutions

Any solution has to make a user leave the untrusted app and use a trusted service. Sorry, that's just how it is. You can't delegate your trust to an unknown entity.

Here are a few possible solutions - with varying degrees of complexity for the user and programmer.

  • Standard web-based OAuth. Take the user to the web where they can check the URL, validate the certificate, see if they're already logged in, etc.
  • SMS based OAuth. Type in your username (only!) to the app, receive an SMS with a one-time PIN/Password. It's the equivalent of "Click here to verify your email address."
  • Message based OAuth. Type in your username (only!) to the app. Receive a Twitter DM with a one-time PIN/Password. Retrieve the message using your trusted Twitter app or website.
  • Use Twitter Digits - only works if the phone number associated with the account is the phone being used.

Look, all of these have a minor impact on how easy it is for a user to sign in. Guess what - so does asking for a password. If we wanted to make sign in nice and easy, we'd just say "Enter your username" and trust that no-one will abuse the system.

We must secure our users and help them to stay secure in the future. Periscope's login model is a retrograde step for user security.

Update!

Here's a video showing the same problem in imgur's new Android app.

4 thoughts on “Web Based OAuth Is A Security Nightmare For Apps

  1. An app could also intercept 2FA by intercepting the SMS that contains the code, could it not? (Assuming it acquired such privileges during installation.) If true, this is kind-of a major problem.

  2. For OAUTH it can make sense to redirect the user from an app to a browser rather than an embedded web view. But I've heard of apps rejected from the iOS store for doing this and told they have to use an embedded view for this task. 🙁

Leave a Reply

Your email address will not be published. Required fields are marked *