Jefferson's Wheel

By Hannah Li

Single Sign-On (SSO) services are widely used in modern web applications for authentication and social networking. While implementing a SSO service for a website is moderately straightforward, building it correctly could be tough and mistakes can lead to serious security consequences. Previous research on Facebook SSO revealed several major vulnerabilities which could easily allow an attacker to obtain sensitive user information or to take full control of a user’s account. These security weaknesses can often lead to token credentials misuse.

Because of these findings, I was motivated to discover whether SSO services implemented with other versions of OAuth would exhibit the same security vulnerabilities. I analyzed Twitter SSO, which is implemented using OAuth 1.0A instead of OAuth 2 which is used by Facebook, for similar security weaknesses. I searched for vulnerabilities by building a web application implementing Twitter SSO and by examining the traffic between the client and the server for patterns and token leakages.

Twitter SSO Protocol: Tokens

The four “tokens” which could be used by an attacker are the Consumer Key, Request Token, Verifier, and Access Token, which will be the focus of this analysis. For the rest of this post, Alice is the user and Mallory is the attacker.

Consumer Key. The Consumer Key and Secret are given to the application when it registers with Twitter. App developers are instructors to keep this key/secret pair secret and if exposed, to generate another key/secret pair.

Request Token. This token also comes in a key/secret pair. This temporary key is issued by Twitter to the application when Alice first requests to sign in with twitter. While the key is shown publicly in the URL, the secret should be kept private.

Verifier. The Verifier is a publicly shown key (in the URL) that Twitter issues to confirm that Alice has approved the application.

Access Token. This key/secret pair is a more permanent token that allows applications to access protected resources on behalf of Alice.

Twitter SSO Protocol: Overview

The diagram below provides a high-level description for Twitter SSO procedure, breaking up the protocol into three steps, each processing an authentication token.

Twitter SSO Protocol: More Details

The diagram below expands each of the three steps. Note that the items written on the arrows do not show a comprehensive list of parameters sent, but rather a few important ones (see Implementing Sign in with Twitter Overview and OAuth Core 1.0a for detailed documentation).

Security Implications

To evaluate the security of Twitter’s SSO implementation, I tried swapping all three tokens for other tokens in different combinations. I did not find any way to use these methods to gain illicit access to private, user information. There are several countermeasures associated with each token that Twitter SSO uses to prevent this type of attack.

Request Token. The Request Token must be connected to the Consumer Key and Secret and expires after the first time it is used to request an Access Token. Due to its temporary nature and correspondence with the Consumer Key and Secret, Mallory cannot exploit the system by stealing this Request Token without also knowing the Consumer Key and Secret, which should be kept secret.

Verifier. Twitter issues a different Verifier each time, thus preventing a malicious party from reusing the Verifier through an impersonation attack. Even through the Verifier is passed through the URL, like the Request Token, Mallory cannot attack the web application without also knowing the Consumer Key and Secret.

Access Token. Each Access Token is connected to a Consumer Key and Secret, which are known only to the application developer. So even if Mallory were to successfully obtain a leaked token over the traffic, she would not be able to use it to log into Alice’s account. This is verified with HuffingtonPost.com, which leaks its Access Token pair through its last message to Alice’s browser. Without this defense, Mallory could have used the leaked Access Token to issue requests to Twitter on behalf of HuffingtonPost.com and Alice.

The last precaution also proved to be useful in another serious mistake in the SSO service. Many tests found that when an application uses the Access Token to request Alice’s information or post on her behalf, Twitter does not check the Access Token Secret, as only providing the Access Token is enough to give the client permission.

This may not pose a realistic security threat because the entire Access Token key pair is typically kept secret, so in order to take advantage of this mistake, Mallory would need to find the Consumer Key and Secret as well. To make the entire system more secure, it is recommended that Twitter verify the Access Token Secret, as many keys and secrets are accidentally leaked through GitHub and even mobile applications when the developers are not careful. When Mallory has both the Access Token and Consumer Key token/secret pairs, it would be much easier to attack a web application.

Though checking the Access Token against the Consumer Key makes SSO safer to use, it has its weaknesses as well. Mobile Applications are easy to reverse engineer since the client code must be made available. If an application needs the Consumer Key to implement SSO, then there is no possible way to build a client-only secure application with SSO since the Consumer Key must be in the code. The secure approach re-routes requests through an application server, which can securely store the key and add it to the requests sent to Twitter. This adds an extra step to app building and many developers may not realize the importance in not including the Consumer Key in the application code.

A recent study from Columbia (Nicolas Viennot, Edward Garcia, and Jason Nieh. A Measurement Study of Google Play. ACM SIGMETRICS, June 2014) scanned thousands of applications in the Google Play Store for token and secret leakages, supports the conclusion that requiring a Consumer Key from the client often leads to faulty implementations. They discovered 1,477 Facebook credentials and 28,235 Twitter credentials among all the free applications when the Facebook SDK is used twice as much as the Twitter4J Library. While their explanation of the significant difference in credentials found makes sense, a more reasonable explanation is that without using a server, it is impossible to implement a Twitter SSO without including the Consumer Key in the code.

Conclusion

While Twitter’s implementation of SSO has security advantages for web applications, it is dangerous for mobile applications. There are two clear options an API developer could use to make an authentication protocol: either you require the server to verify the Consumer Key and Secret during each step of the procedure, or you don’t, hoping that Mallory does not gain access to key information. The latter option, however, leads to many vulnerabilities as clearly seen with Facebook SSO. The first, seemingly more secure, choice causes mobile applications to sacrifice the security of an OAuth protocol.

The Examiner has an article on Facebook privacy issues: To Facebook or not to Facebook, 29 June 2009.

The second approach is even scarier, a feature of Facebook which allows outside developers to create small programs called “applications” for members to do things like playing poker, getting daily horoscopes, and sending each other virtual fantasies. With the younger set, the latter must cause parents a lot of consternation over their kids. Word is there are about 24,000 applications that have been built by 400,000 developers.

And here’s the kicker. Once these developers have your personal data, there is nothing Facebook can do. Adrienne Felt of the University of Virginia investigated the procedure in her thesis and found out that 90 out of 150 of Facebook’s most popular applications (that’s 60 percent) have unnecessary access to your private information.

Jake Widman has written an interesting article about the impact of “oversharing” on Facebook: How Facebook mucks up office life: Managing a workforce is already a challenging job; now Facebook and other social networks raise a host of sticky new situations., ComputerWorld, 30 April 2009.

The key observation is the way social networks mix different social circles that would rarely intersect in real life, along with people’s willingness to accept friend requests from unknown or unvalidated individuals.

Separate from the social challenge is the issue of people, particularly younger Facebook users, becoming friends with people they don’t know well, or even at all. “Facebook doesn’t have our normal social mechanisms for validating someone,” Argast points out — and many users, especially people who use Facebook to network, are reluctant to turn down a friend request.

The article mentions studies that indicate both that a significant fraction (23%) of hiring managers check social networking sites on potential hires, and that the majority of Facebook users do not understand how visible their “private” information is.

The article also highlights the additional risks of applications.

A further issue is the fact Facebook applications gain access to — as the warning screen tells you — “your profile information, photos, your friends’ info, and other content that it requires to work,” whether they need it or not.

In 2007, Adrienne Porter Felt, then a computer science student at the University of Virginia and now a student at U.C. Berkeley, and David Evans, an Associate Professor of Computer Science at the University of Virginia, did a survey of the top 150 Facebook applications and found that “90.7% of applications are being given more privileges than they need” to perform their intended functions.

The researchers haven’t updated those earlier findings, but Evans says he suspects the results would be pretty similar. “If anything, the applications are getting more complex,” he says. “And there is also an emerging model for third-party advertising networks embedded in applications, which has further privacy risks.”

In summary,

Bottom line? Facebook doesn’t call for new principles, Selvas says, just smart application of the old ones. And the constant reminder that you and your employees are in public when you’re on Facebook. As Selvas sums up, “Don’t do anything on Facebook you wouldn’t do in an airport.”

The New York Times has an article on social network privacy issues including the risks of third party applications: When Everyone’s a Friend, Is Anything Private?, New York Times, 7 March 2009 (by Randall Stross, Digital Domain column).

FACEBOOK has a chief privacy officer, but I doubt that the position will exist 10 years from now. That’s not because Facebook is hell-bent on stripping away privacy protections, but because the popularity of Facebook and other social networking sites has promoted the sharing of all things personal, dissolving the line that separates the private from the public.

…

Facebook’s default settings for new accounts protect users in some ways. For instance, the information in one’s profile is restricted to friends only; it is not accessible to friends of friends. But Facebook sets few restrictions by default on what third-party software can see in a network of friends. Members are not likely aware that unless they change the default privacy settings, an application installed by a friend can vacuum up and store many categories of a member’s personal information.

David E. Evans, an associate professor of computer science at the University of Virginia, says he wishes that Facebook would begin with more restrictions on the information that outside software developers can reach. For 15 of 19 information categories, Facebook sets a default setting of “share,” which means the information can be pulled out of Facebook and stored on servers outside its control. These 15 categories include activities, interests, photos and relationship status.

“Facebook could set defaults erring on the side of privacy instead of on the side of giving your information away,” he said.

Chris Kelly, Facebook’s chief privacy officer, defends its current settings, saying it “gives users extensive control over the applications they choose to interact with.” He also said Facebook had removed “thousands” of applications that members deemed untrustworthy.

In Professor Evans’s view, however, banishment of malevolent software comes too late: “Once the application has got the data, it’s got it, stored on someone else’s machine.”

The defaults turn out to be crucially important, because few users go to the trouble of adjusting the settings. Asked how many members ever change a privacy setting, Mr. Kelly said 20 percent.

Don Tapscott’s new book, Grown Up Digital: How the Net Generation is Changing Your World, includes a brief description of Adrienne Felt’s work on social network privacy:

I’m still worried, though, and I’m not alone. According to Adrienne Felt, the coauthor of a 2007 study on social networking privacy, the new measures do not fix a key problem. You can decide which of your friends can see what on your profile, and you can stop the applications that your friends install from peering into your Facebook world. But, if you install an application — say, a photo editing application that lets you put Angelina Jolie’s hairdo on your best friend’s high school graduation picture — the maker of that application can see anything you put on your profile, like your dating interest, your summer plans, your political views, your photos, the works. The only way to stop the application developers from peering into your own Facebook world, Felt says, is to not put any applications on your personal profile. The vast majority of applications don’t need your private data to do their thing, she notes, and yet all of them have access to whatever you can see. [footnote that references our Privacy by Proxy paper]

I tried the book’s website http://grownupdigital.com/, but get:

PHP has encountered an Access Violation at 7C81BD02

Perhaps the digital world is not fully grown up yet!

Jonathan McCune successfully defended his PhD thesis at Carnegie Mellon University last week. Jon (sorry, that’s “Dr. McCune”) was an undergraduate researcher in our group from 2001-2003, when he worked on agent-based software (for our RoboCup team) and adaptable sensor network security, before joining CMU’s PhD program in 2003. Dr. McCune’s recent research has focused on leveraging trusted hardware to build secure systems.

Congratulations Dr. McCune!

UVa Today has an article about our (myself, abhi shelat, John Lach, and Ben Calhoun) recent NSF Cybertrust grant on RFID security and privacy: U.Va. Team Receives $1 Million Grant To Improve RFID Security, by Brevy Cannon, 9 January 2009.

Some excerpts:

To address the problematic use of custom cryptography, the U.Va. research team will develop an encryption scheme that is relatively strong — providing some measure of privacy and security — but that can be implemented at almost zero cost by repurposing the meager hardware resources already available on common RFID tags. Providing a solution that adds virtually no cost is crucial, because these RFIDs are made by the billions, at such low costs (5 cents or less apiece) that there is no margin for any added expense.

…

The team is breaking new ground by using a holistic design approach that considers how all the various levels of the design — the hardware, the encryption algorithm and how it is used — work together, mindful of how an attacker will target the single weakest link in the design.

…

The research team hopes their research will forestall that possibility, enabling RFIDs to be used in countless ingenious applications not yet dreamt of, without sacrificing privacy and security in a Faustian bargain.

The story about Adrienne Felt’s Facebook privacy study made the list of UVA Today Most Popular Stories of 2008.

Fast Company has an article (by Brendan Collins) on Privacy and Security Issues in Social Networking.

The reason social network security and privacy lapses exist results simply from the astronomical amounts of information the sites process each and every day that end up making it that much easier to exploit a single flaw in the system. Features that invite user participation — messages, invitations, photos, open platform applications, etc. — are often the avenues used to gain access to private information, especially in the case of Facebook. Adrienne Felt, a Ph.D. candidate at Berkeley, made small headlines last year when she exposed a potentially devastating hole in the framework of Facebook’s third-party application API (application programming interface) which allows for easy theft of private information. Felt and her co-researchers found that third-party platform applications for Facebook gave developers access to far more information (addresses, pictures, interests, etc.) than needed to run the app.

…

Will there ever be a security breach-free social network? Probably not. “Any complex system has vulnerabilities in it. It’s just the nature of building something above a certain level of complexity,” says professor Evans. According to Felt, the best idea is a completely private social network. “It simply requires that there’s no gossip in the circle, by which I mean one person who sets their privacy settings so low that third parties can use them to get to their friends.”

“Social networks are great fun, and can be advantageous but people really need to understand that it’s complicated world and you need to step wisely,” Cluley says.

Marc Rotenberg, Executive Director of the Electronic Privacy Information Center, has written an opinion piece for the Sacramento Bee on social networking privacy: Online friends at what price?: The point of social networking is to share your personal information with the world, The Sacramento Bee, 20 July 2008.

Many of my friends were surprised when I signed up for Facebook. “Why would a privacy advocate put personal information online?” they asked.

“For the same reason that people use the Internet for e-mail or pick up a telephone to make a call,” I explained. “It’s very useful. Of course, there are real privacy issues. We should understand them and fix them.”

Today Facebook is both very useful and a genuine privacy threat. …

Privacy problems have continued to plague the service. In May 2007, Facebook opened up the network for software developers to create applications such as Scrabulous that appear on Facebook pages. Some of these programs are very cool, but that doesn’t answer the privacy problem. Application developers were given access to the detailed personal information of the user as well as the friends of the user. And that means just about everything in your profile, from relationship status and education history to copies of photos and favorite movies. And amazingly, the data of your friends, who did not sign up to install the program, have their data gathered up by Facebook and sent to the developers.

Earlier this year, researchers at the University of Virginia found that Facebook was providing access to far more personal information than was necessary; in fact, information that the developers were not even seeking. As lead researcher Adrienne Felt pointed out, this was a dangerous security practice because it created unnecessary risks for Internet users.