That’s misguided. There may be some very good reasons to implement shield Y.

Consider the utility of a safety parachute. A determined attacker trying to kill you will obviously sabotage the safety parachute just as easily as he can sabotage the primary one. So, does that mean you might as well jump without a safety parachute? Of course not. You want to take into account not just the worst-case attacker, you want to take into account your own stupidity. A safety parachute means that, if you packed your primary wrong, you can still live. Defense in depth, as it’s more commonly known in the security community, is usually not about building the 12 layers of security around the “Die Hard” vault that a skilled attacker has to vanquish, one by one. Defense in depth is the humble realization that, of all the security measures you implement, a few will fail because of your own stupidity. It’s good to have a few backups, just in case.

In my previous post regarding Twitter, two people I greatly respect, Miguel de Icaza and Keith Winstein, claimed Twitter’s requirement that desktop clients identify themselves with a consumer name and secret didn’t make any sense, because a malicious app could easily bypass that defense. This is true. But what about the apps that have bugs? The ones that start double posting when the date hits 9/02/10 because of some date parser bug combined with a fetish for the 1990s TV show? Or the ones that have a buffer overflow error that a remote attacker can trigger and start partially remote-controlling? How does a developer, or Twitter themselves if that developer isn’t responding, shut down that faulty pipe? The consumer name suddenly looks like a decent solution to this problem. It doesn’t work against the worst-case attacker, but it works against failure modes where the desktop app developer isn’t malicious, only a little stupid.

(I say this with all the love in the world for developers and their stupid bugs, since I include myself proudly in that group: we developers make mistakes, all the time, often stupid ones.)

There are a few other good reasons, along the same lines, for requiring a desktop client to use access tokens rather than passwords. For one, it’s good protection against developer stupidity to simply not store the user’s username and password whenever possible. That’s just one less place from where the user’s password can be compromised and, when apps identify themselves, it’s easier to shut down that app independently for any number of reasons: the user lost their laptop, or the app is misbehaving in unintentional ways, …

Does any of this provide a defense against the worst-case attacker, a rogue desktop app? Of course not. But thinking only about the worst-case attacker misses the obvious issue in distributed software design: stupid mistakes are by far the most likely problem you’ll encounter, and it’s a good idea to design a few layers of control to address those issues when they arise.

Defense in depth. Sometimes it means hedging against your own stupidity.

the consumer secret is not important

The article’s main argument is that the oAuth consumer secret is embedded in desktop clients and can be extracted. Yes. That sounds really bad doesn’t it? Except, as the article itself says:

It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.

Ahah, you say, but the article also says:

the problem is how Twitter is using the key

Oh no! What are they possibly doing with this key that they shouldn’t be doing?

These keys are particularly significant because Twitter has configured them to enable access to special APIs which aren’t generally available yet that can be used to exchange login credentials for an access token

So in other words, with a consumer secret, you can exchange a username/password for an oAuth access token. That’s not ideal, because it means that we’re back to clients proxying usernames and passwords, but how is that a compromise? If an app successfully captures your username and password, and the app is evil, you’re screwed already! In fact, it’s probably a good thing that Twitter then pivots and says “ok, fine you got the password, but can you please just exchange it for this access token now and not store the password?” Furthermore, Twitter even says that this approach, which they call xauth, is the “least desirable way to authenticate,” and they require apps that want to use this feature to request special approval.

I don’t see a security compromise here. I see a complicated set of design issues on which Twitter is trying to make practical security decisions. It’s certainly reasonable to disagree with them, but it’s unwarranted to claim that oAuth security has been “compromised” or that Twitter made this decision “against all reason.”

spamming is a darn good explanation

The article says:

The issue here is that Twitter wants to use the keys as an abuse control mechanism to centrally disconnect spammers and other unwanted users of the service, but OAuth was simply not designed to be used for that purpose. The idea is that centrally disabling a spammer’s consumer secret key will lock out all of the spammer’s user accounts, theoretically simplifying spam control for Twitter. It’s unlikely that this naive strategy will work in practice, however.

Any spammer with a hex editor can trivially compromise the keys of popular applications and use those keys to evade Twitter’s abuse controls.

Ummm, no. As the article itself states, a spammer who takes another application’s keys still doesn’t have the access tokens, and so it cannot spam.

In fact, spamming is a very good reasons for Twitter’s use of consumer keys and secrets even in desktop clients: a spammer in this case is going to be an application that has legitimately authorized a bunch of users, and then decides to go crazy and spam their feeds. In that scenario, Twitter can very easily temporarily disable that one consumer key+secret, or throttle it, or kill it altogether, without having to trace down all the access tokens that consumer generated. I like this reason a lot.

increase the risk of phishing? No

In the past, I’ve been critical of OpenID for increasing the risk of phishing. So one might think I would agree with the article when it says:

Individual implementations aside, the general concept behind OAuth’s redirection-based authorization process materially increases the risk of phishing. The people behind the standard are fully aware of that fact, but they don’t believe that the issue should necessarily be addressed by the standard itself.

I think that’s wrong. There’s a key difference here: what’s the alternative to oAuth? The alternative is the password anti-pattern, where all those third-party apps capture your username and password. So sure, it would be good if oAuth providers had more phishing-resistant login mechanisms, say like BeamAuth (shameless plug). But, on the whole, oAuth is still a heck of a lot less phishing-prone than the password anti-pattern it’s trying to replace.

open-source and DOS: fair points

The article does make a fair point about open-source software, JavaScript-based clients, and generally the possibility that some loser might sabotage a legitimate app by copying a consumer token and secret and abusing it. If that happens a lot, then Twitter will certainly have to come up with a new approach. But let’s at least understand that there is no good approach to this problem. If no attempt is made at tracking which client is which, then one bad spamming apple could ruin it for everyone, since there’s no way to differentiate the good from the bad. Twitter may have to rethink its automatic consumer-kill policy and become a bit more nuanced, but that’s just a policy decision. At the protocol level, I don’t know how they could do much better, given that even closed-source software, as pointed out by the article, can be easily disassembled.

override the callback URL? That’s a good point

The article claims that an attacker can change the callback URL in a Twitter oAuth session, which would indeed enable a very sneaky phishing attack. I didn’t think that was the case, but it may be. I agree with the article’s take on this:

Ideally, OAuth implementors should require application developers to supply the callback address when they configure their key and should not allow that setting to be overridden by the client application in a request parameter. Twitter has a field in the key configuration that allows the developers to specify a default, but they still allow client applications to use the dangerous callback override parameter.

I think the article is right on this point. There are many reasons to disallow callback overrides, and there’s no good reason for it: oAuth web apps need cookie-based session support anyways to complete the oAuth process, there’s no need to dynamically add state to the callback URL. It would be good to do away with this “feature.”

a few very good small points

The article makes some very good smaller points that Twitter (and other oAuth providers) should heed:

• debugging oAuth is hard, and having more explicit error messages is a good idea
• logging out is confusing: if you log out of the app, are you logged out of the oAuth identity provider? Flickr does this very well with Yahoo ID integration, so oAuth and Twitter should indeed provide more guidance on this front.
• giving users more cues for trusting certain apps is probably a good idea. This can evolve over time, though, and the protocol won’t need to change.

These are all useful points. But they’re small, and they do not warrant a big scary title.

all hail oAuth 2.0!

The most confusing part of the article is the constant harping on oAuth 1.0a as “immature” when it has been deployed by dozens of high-profile providers, and the constant praise of oAuth 2.0, which has only just been released and actually weakens security to make developers’ lives easier (I’ve written before about the oAuth 2.0 problems). It’s possible that oAuth 2.0 is much better in ways I haven’t considered, but where’s the evidence? The article doesn’t say.

unnecessary insults

The article concludes:

Although I think that OAuth is salvageable and may eventually live up to the hype, my opinion of Twitter is less positive. The service seriously botched its OAuth implementation and demonstrated, yet again, that it lacks the engineering competence that is needed to reliably operate its service. Twitter should review the OAuth standard and take a close look at how Google and Facebook are using OAuth for guidance about the proper approach.

There’s no evidence of this so-called “botched” job. Sure, some smaller points are absolutely worth considering, and I applaud the author for digging deep on some of these. But I find unfortunate the overall tone of the article, the baseless and gross exaggerations, and the condescending writing that ignores reasonable justifications for Twitter’s decisions.

The voting crowd is emerging from a 2-day workshop with election officials on remote voting for military and overseas voters. I’m trying to get a sense of attendees’ impressions from that workshop, but suffice it to say that it seems to have been “exciting.” Ron Rivest compared online voting for public-office elections to drunk driving, as in “there’s no good way to do it,” and that apparently didn’t go over very well with some folks. I agree with the metaphor, however harsh it may seem.

Meanwhile, there is plenty of room for online voting in the numerous elections people hold that are not for public office: corporate boards, clubs, student government, etc. That’s why I’m excited that last night, we released Helios v3. Try it out right now by voting in our super geeky sample election and in a current-events election (Wyclef for Haiti?).

More than 25,000 votes have been cast using Helios technology. We’ve learned some very interesting lessons already, and there are many more to come. I’m hoping that, as we add more social aspects to Helios, we’ll see more usage, more data, and a unique chance to improve the technology based on real-world experience.

In every instance, the companies involved didn’t mean to cause these data breaches. In every instance, they would gladly pay serious cash to prevent these bugs, given the negative publicity they cause. In every instance, most security folks I know are unfazed by these news, which they find quite unsurprising. And in each instance, the companies in question, Facebook and Google, reacted admirably: rapid disclosure, rapid response.

If you’re shocked, outraged, writing lengthy TechCrunch posts about these developments, you probably don’t understand computer security very well, and you’d better sit down with a stiff drink, because these issues are the tip of the iceberg. Accidental breaches happen all the time. Writing secure software is incredibly difficult, especially when, like Google and Facebook, you’re pushing the envelope and releasing features as quickly as possible to outpace your competitors.

We do not know how to write secure software. We do not know how to ensure that the software we write follows a given set of policies. Anyone who tries to sell you a perfectly secure system is either lying to you or doesn’t know what he’s talking about.

There are measures we can take to minimize risk, but they aren’t very sexy. Mistakes will be made, so the point is to minimize the bad consequences of those inevitable mistakes. Think of the awfully boring things you’ve heard security geeks tell you:

• don’t store user passwords in the clear.
• don’t make up your own crypto protocols, be conservative.
• defend in depth: even if you’ve got one defense, it’s always a good idea to have other defenses against the same potential breach.
• look upon large data aggregations with deep skepticism: Google, Facebook, government DNA databases, etc.
• look upon wide-ranging integration of disparate systems with deep skepticism: OpenID, Facebook Instant Personalization, etc.
• be skeptical of software vetting claims, i.e. the Apple app store.
• ask that new protocols do much more than be “no less secure” than existing protocols (I’m looking at you oAuth 2.0, no less secure than cookies).
• demand that the public be informed of all significant data breaches.

So freaking boring, right? But that’s real security. Minimize the target, minimize the risk, maximize the defenses, and always seek to strengthen security measures, because attacks only get stronger, too. And finally, provide the incentive to companies to constantly improve their defenses, by mandating disclosure.

If you’re shocked about the Facebook and Google bugs, just remember that those are the bugs we know about. There are a whole bunch more we don’t know about that Google and Facebook caught before any harm occurred. And there are a whole bunch more that nobody but bad guys know about that are actively causing harm right this minute. So the question is, as a software engineer, did you take those boring precautions to limit the damage? As a user, did you consider what data you’re storing with whom, how big a target they may be to attackers, and how motivated they are to truly secure your data?

This weekend, as hundreds of thousands of people explored their iPads [...] they found [...] an application called Facebook Ultimate, featuring a sleek version of the familiar ‘f’ logo. The application quickly rose through the ranks to become one of the App Store’s top selling iPad applications. Unfortunately, it soon became apparent to these users that the application simply wasn’t very good, and that it wasn’t created by Facebook at all.

[...]

the $2.99 application rose to become the #7 top paid app on the App Store. The app received many poor reviews from upset users, plenty of which warned others that this was not the app they were looking for, but that apparently didn’t stop people from downloading it.

Tell me again how the App Store protects users?

Today, Mozilla is proposing an interesting way to “plug” this leak, by attacking the problem from both ends. First the style changes for visited links are now limited: you can’t change the font-size of a visited link. Second the web page can no longer fully introspect and discover those small style variations that are still allowed. It’s really fantastic to see Mozilla working on this particularly nefarious issue, which has been one of the elephants-in-the-room of web security for the last few years.

But I’m not sure this approach is the right one. It is, exactly as Mozilla put it, a “plug” for a leak. It doesn’t really address the essence of the issue, and I suspect clever attackers will find other, smaller leaks to exploit. Meanwhile, setting the precedent that the browser will now fake some of its rendering information to the page’s own JavaScript is a little bit odd.

The core issue is that a web page is allowed to use private information it should never have access to as a kind of black-box processor on its own rendering. That may have been fine when web pages were static content, but now that web pages are full-fledged programs that can attack these black boxes a thousand times a second without the user noticing, it’s a problem.

An Alternative: tweaking the meaning of ‘visited’

So here’s my proposal (which may well have been mentioned by others before me.) a proposal I thought I’d come up with, but really is just a subconscious reappearance of work by Collin Jackson, Andrew Bortz, Dan Boneh, and John Mitchell: safehistory.

A browser should consider a link “visited” depending on where that link appears. If I’ve clicked on cnn.com/stories/123 from fooblog.com, then the next time that link is shown on fooblog.com, it should appear as visited. But if that same link appears on barblog.com, then it should simply be considered a new link.

That way, a web page only has access to information that it technically already could have collected itself, by tracking the outgoing clicks on its site. No more black-box access to private data that it can manipulate thousands of times a second. No more leaks to plug (in this context). Conceptually, this is cleaner and much more in line with the security model we need for the Web.

Also, I have a feeling that this might be a better mental model of how most people think of visited links. A visited link, in this new model, means “I have already followed this path from A to B,” rather than “I have already seen B via some other site C.” After all, how often do people find the same link from two different sources at different domains? It happens, of course, but how often is it useful to know that this link was visited via a different path when the anchor text at both sites will almost certainly be different, making the information that you’ve already visited this site fairly vague (which site was it?)

But what about link aggregators, like reddit, digg, etc…

Some sites just aggregate tons of links to stories around the web, and in those cases you might want to know that you’ve already seen the story via some other link-aggregator or even on your own. Now, that need may be a lot less important than you think initially: often links from aggregators are customized with outgoing link-tracking, referrer codes, etc.. that actually prevent visited-link-highlighting from activating anyways. But, this may be a legitimate case where advanced users want to know that they’ve seen these stories before. In those cases, I can imagine a “super-referrer” whitelist in the browser, where certain sites are trusted not to abuse their ability to use your history black-box rendering processor. Advanced users would have to add the link aggregators they trust to this whitelist.

Because it’s about trust

At the end of the day, it’s about trust. We should not trust random web sites with black-box access to programs that depend on our private data. If I’ve never clicked on a link from site A to site B, then site A should know nothing about site B, and should not be able to run some program that very tightly depends on information about my visit to site B.

A visited link should mean “you’ve already walked this path before,” not “you’ve already seen this destination.”

This is different. Much more natural to use, a different experience altogether. It’s going to sell like mad, and developers will be building apps for this in no time.

The real Apple fanboys (I’m only a poser Apple fanboy) are saying almost what I’m saying: this is a new model of computing, the critics are suffering from future shock. Yes, and yes.

That said, the Apple fanboys are taking one critical step too many by accepting the hand-waving argument that this revolutionary computing model justifies the Apple-controlled App Store. Apparently, it’s like driving an automatic vs. a stick-shift, or better yet it’s like the Prius where you need special skills to maintain it. Spare me the kool-aid, these analogies are incredibly bad. If you really want to use that analogy, at least realize that adding your own app to a computer is more like installing a GPS on the dashboard, not tuning the engine. Would you be okay with a Prius if somehow you didn’t have the right to install Honda-made seat covers, or tires made by Michelin? Well, if the Prius were good enough, you’d grind your teeth and deal, but in what world would you argue that it’s a feature that you can only install seat-covers approved by Toyota?

Yes, the iPad looks amazing, and yes, it will sell lots, and yes, it will redefine the way we interact with computers. But would we lose any of those things if Apple allowed you to add your own applications? No. The Apple death-grip is entirely orthogonal to all of those wonderful things. There could be a scary-red toggle deep down in the preferences, or a magical swipe pattern, or a software download from the Apple site with a big fat warning that says “be careful, if you enable the ‘risky install’ feature, you may be forced to reset your iPad to factory settings.” Most people would use the iPad untouched, but the ability to open it up to other stores would bring more competition and would prevent the App Store overlords from making clearly anti-competitive decisions like rejecting the Google voice app.

So I was right about one thing: the iPad is going to move us one step closer to Zittrain’s dystopic Future of the Internet. But because the iPad is much more of a general computing device than I expected, that step is going to be a much larger step, and Zittrain’s vision is coming true much faster than I thought. And that part is incredibly sad, no matter how badly I want to edit slides using finger-swipe gestures.

1. the video stream is not that useful to enemies, and
2. given that many people need access to the video feed, the key distribution problem would be very difficult to manage, and some allies could be severely handicapped if they happened not to have the key.

So, Bruce is typically fantastic at finding those interesting areas of security where the answer is counter-intuitive. But huh? How can both of those points be true? If the video stream is valuable to allies, then I’m guessing it’s valuable to enemies.

But let’s say that, somehow, these contradictory points are, in fact, both true.

There isn’t a key management problem here. The command-and-control signal is already encrypted and authenticated, so the video feed could be encrypted via the same exact route back to the home base (which needs to happen anyways so the NSA pilots can, you know, pilot), at which point it is decrypted and can be syndicated to allies, troops on the ground, commanders, etc… I just don’t see the argument for the signal to be directly received by local troops, when the one person who needs the signal the most anyways is already sitting thousands of miles away.

Bruce is right that key management is often a very complicated problem. But I just don’t see how it’s relevant in this case.

I definitely sympathize with “it’s hard to get security right,” and I certainly agree that we should begin to standardize oAuth libraries ASAP. The reference implementations are okay, but they’re not solid enough for widespread standardization, which means people are cooking up their own, which is bad news. So yes, being able to delegate the security implementation to a well tested library is a good idea.

But I don’t think server-side SSL replaces the security we got from HMAC-signed requests. The key idea of signed requests is that if I intercept a request, I can’t steal the credentials. The only way SSL compares is if certificates are definitely checked or if client-side certificates are used for authentication. I don’t buy the argument that oAuth WRAP client-side libraries will do proper certificate checking. And I think that, while very cool, client-side SSL certs would make life potentially more complicated for developers (and would rule out JavaScript implementations for the foreseeable future.)

I’m very open to the idea of simplifying oAuth, and maybe there’s something to oAuth WRAP that I’m not seeing…. but the point is, the current oAuth WRAP security claims are, I believe, misguided in practice, and I hope the oAuth WRAP team thinks this through a bit more before all the big name web sites standardize on it, and the next favored technique for hacking your Facebook account is DNS spoofing the oAuth WRAP transaction.

The main difference between OAuth and OAuth WRAP is that WRAP does not have elaborate token exchanges or signature schemes. Instead, all server-to-server WRAP calls happen via SSL. The “access token,” which grants your client the ability to make API calls on a user’s behalf, is protected by SSL rather than by a shared secret and signature scheme.

If I understand correctly, the experience is the same for the user, the connectivity requirements between the data host and the third-party consumer remain the same, but now we’ve gotten rid of those pesky signatures and instead we’re sending tokens in an HTTP header a bit like a password.

So, like a password, it can be replayed. And intercepted via Man-In-The-Middle. Oy.

But wait, you say, don’t worry, the token is sent over SSL, so it’s all good.

Right. What’s going to happen when someone “forgets to turn on SSL”, which is all too common when security is abstracted out “somewhere down in the stack.” Or when we stop dealing with those pesky certificate errors and just choose not to validate the cert, which will leave the protocol wide open to network attackers who can now literally play man-in-the-middle just by spoofing DNS on a wifi network, capturing the token, and replaying it to access all sorts of additional resources, effectively stealing the user’s credentials.

This might actually be worse than passwords, because at least you can work to educate users about SSL (and after their Facebook account gets hacked, they might actually care), but it’s very hard for users to gauge whether web applications are doing the right thing with respect to SSL certs when the SSL calls are all made by the backend which has trouble surfacing certificate errors.

I understand. Security is hard. Getting those timestamps and nonces right, making sure you’ve got the right HMAC algorithm… it’s non-trivial, and it slows down development. But those things are there for a reason. The timestamp and nonce prevent replay attacks. The signature prevents repurposing the request for something else entirely. That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling.

I see reasons to simplify oAuth. Maybe rethink the combination of consumer and access secrets, which is a bit messy. Maybe rethink the token renewal process and make it part of the core. But removing signatures? I think this is asking for long-term trouble in exchange for a modest amount of short-term simplicity.