OAuth 2.0 is not perfect from a security perspective but as Tim Bray says this is Pretty Good Security meets Pretty Good Usability. Makes sense to me - we have to stop using passwords and we have to do so in a way that won't have developers rioting in the streets and burning cars. But why be happy about shipping something that has a 70 page long threat model in its wake? This dev comment from the blog announcement says it all- "After implementing my own authentication for my app, I really would have appreciated something like this!"
Point is, “Out of the crooked timber of humanity no straight thing was ever made", this is forward progress because custom access control implementations will be definitely worse, and yes I have seen this many times.
So yes its progress, Why did it take so long - who knows? But here we are.
Its helpful to track evolution through a Crawl - Walk - Run maturity curve.
From where I sit, Crawl has been achieved with this release - a standard way to register your app, get a token and use it - plus many future apps that do not rely on passwords, but what about walking and running?
Walking should be about not just using a standard protocol as an improvement over ad hoc access control but also using the protocol safely. Its an access control protocol after all, its failure modes are ugly and have consequences to users and platforms. A chainsaw is great for cutting timber and its an excellent way to cut off your own limb(s). Use of a safer protocol is desirable but guidance on safe use is required to get full value. This release is not quite there yet. OAuth tokens, like anything else, have vulnerabilities large and small, but in removing crypto and signature functions the implementation increases its reliance on TLS for security. Fair enough for many apps, but there is no way to discern this from the documentation, SDK, and APIs. The OAuth 2.0 protocol, by itself without TLS, is not good enough.
"The sign above the players' entrance to the field at Notre Dame reads 'Play Like a Champion Today.' I sometimes joke that the sign at Nebraska reads 'Remember Your Helmet.' Charlie and I are 'Remember Your Helmet' kind of guys. We like to keep it simple."- Warren Buffett
OAuth 2.0 should be shipped with a 'Remember TLS' reminder stapled to each and every release. Otherwise, numerous threats are in play. OAuth 2.0 with TLS meets the Pretty Good Security bar for many apps, without TLS its playing without a helmet.
Further, both the client and server side developers have some work to do to avoid shooting themselves in the foot with the protocol, for example the client developer may not realize the sensitive nature of the token and how best to protect its storage. The server side developer deals with a myriad of concerns like session management, linking the token to access control, replay and others that in most/all cases mirror the issues for most webapp security. Here we face two challenges though developers not being trained up on security protocols and so miss a lot of the subtleties and nuance in deploying security protocols. And infosec blithely assuming that silver bullet - this all singing all dancing protocol solves my problem is all too common. Not saying Google is fomenting either of these but I see it in the trenches every single day. I would prefer to see Google include a short and sweet Security Checklist to make sure people remember their helmets. Do not have to reinvent the whole Threat Model but guidelines for safe use would get this a long way towards Walking in my view.
The worst security posture is not being insecure, all systems have vulnerabilities, the worst security posture is to assume you are secure when in fact you are not. Here the current implementation is lacking and tailored guidance and/or checklists from client and server side developers' perspective to know what the protocol is doing and what it is not doing would be very useful. I know this just shipped, but this gap should be closed soon. As a group, developers across the globe have had zero training in secure coding. When I go into train a dev team on secure coding, even those with decades of programming experience, I am likely teaching them their first day of secure coding. You cannot expect them, even good developers, to know all the right things to do, and to pick up on the subtleties at work in implementing security protocols. I am all for finding the balance on Pretty Good Security and Pretty Good Usability - that's a worthy goal, but the dots need to be connected. There's a world of difference between https://sites.google.com andhttp://myappisowned.com, Google's Android team should help to close these gaps out, clearly state what can and should be done to foster safe use of OAuth 2.0.
Implementing security protocols is a new proposition for most developers, they were never trained but back in the day it never mattered, the container or server did for them and the threat was not high. Neither of these is the case today any more. This stuff matters. We could easily do a "how to break Android" class and get the security people all fired up to attend, but what would that solve really? We need to start building better stuff and we need developers in the game to make progress. This is Why We Train. OAuth 2.0 and TLS can improve the security in most mobile apps, implemented wrong they can also make it worse. There are design and implementation things to consider from Crawling to Walking, but developers need to know what they are to make it happen- we tackle these on Day One of Mobile AppSec Triathlon.
**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.
No comments:
Post a Comment