Twitter Development: The Pitfalls of Basic Authentication

This article is excerpted from Chapter 6: Basic Authentication and OAuth of the Wrox book, Professional Twitter Development: With Examples in .NET 3.5, by Daniel Crenna, and is reused by permission of the publisher. This may not be reused without publisher permission.

“There have been tons of third party applications built around Twitter but the problem with them is users aren’t interested in entering their Twitter username and password to check them out. OAuth changes that by allowing users to grant permission once they’ve logged into Twitter providing better security.”

    — Keith Elder, Witty

Up to this point, you have used Twitter’s Basic authentication scheme to make your calls against the API. You’re also aware that Twitter prefers OAuth authentication, a new standard created by several prominent social web service developers, and that it may remove support for Basic authentication in the near future. Keep in mind that although it is easy to interchange the concepts of authentication and authorization, OAuth specifically handles the challenge of user authorization of API access. The actual authentication of a user’s credentials is delegated to the publisher site, i.e., Twitter, which your application intends to consume.

The Pitfalls of Basic Authentication

Your calls to the Twitter API requiring user credentials utilize Basic authentication, a convenient method of passing these credentials over the web to remote sites in an HttpWebRequest; this authentication scheme is painless to implement, but it has several serious flaws that you should consider.

User Credentials are Visible

In Chapter 1, you learned how to make authorized web requests using Basic authentication, and learned that the authentication pair you provide in the authorization header, the username and password, is Base64 encoded and inserted directly into the request as plain text. Although this isn’t human readable, you also know that converting back to ASCII from Base64 encoded strings is trivial. Anyone monitoring your Twitter network traffic would see the password plainly, illustrated by the following example:
    GET /statuses/user_timeline.xml HTTP/1.1
    Authorization: Basic c2VjcmV0YWdlbnRtYW46MDA3
    Connection: Keep-Alive
The Base64-encoded authentication pair in the monitored outgoing request is easily decoded with sample code in Chapter 1, revealing the plain text secretagentman:007; not exactly secret anymore!

Credentials are Reusable

The ability to easily read credentials from outgoing HTTP traffic is one thing, but Basic authentication also suffers from the fact that the credentials used with one request are reusable for any request for the same user. This is the traditional sense of a username and password, where the same credentials grant unlimited rights to the user’s privileges, and provides a hacker with the maximum ability to cause damage to the compromised user account.

Credentials are One-Way

Basic authentication has no sense of which provider a user’s credentials are for. This means the provider has no way to automatically intervene on the user’s behalf when accounts are compromised. A Princeton study calledReuse and Recycle: Online Password Management (and available by visiting ) found that many people choose to use the same password for multiple sites they visit. The reuse of passwords combined with the atomic nature of user credentials that don’t include meta-data about the intended web site target makes it impossible to prevent tampering when a hacker successfully steals a user’s password.

Existing Alternatives to Basic Authentication

Basic Authentication’s shortcomings are well known, and existing standards are already in place to address the problem of secure transmission of credentials on the web. Two widely adopted approaches, which Twitter does not use, include HTTPS and Digest authentication.


One school of thought in security targets the vehicle of transport for messages rather than attempting to obscure the details of a publicly visible message, as is the case when communicating over HTTP. A popular form of transport authentication is a combination of Secure Socket Layers (SSL) layered over HTTP. In general, it is expensive to set up and maintain, due to the external nature of the security certificates that are used to verify that the web application employing HTTPS, the protocol that allows protected transports, is the application it claims to be. This is an impediment to many social services that begin as startups with constrained budgets, especially for services wanting to use HTTPS to protect web APIs such as Twitter’s REST API, because it would require purchasing a certificate for every user to authenticate them.

Digest Authentication

Another way to compensate for Basic authentication, especially when HTTPS or another transport security mechanism is too financially prohibitive, is to use a form of authentication that introduces unknowns that are not observable in the message body itself. Though you will learn about OAuth in this chapter, Digest authentication is similar to OAuth as it involves introducing secret keys to enhance the level of security over an inherently insecure transport such as HTTP. Digest authentication works by replacing the actual user credentials with an MD5 hash of those credentials. It is coupled with the realm of the requested service, as well as a nonce—a randomly generated value that is only used once—and is therefore able to prevent the security implications of credentials that are not tied to the specific request.
When Twitter Was Hacked
In January 2009, several prominent Twitter users, such as Fox News, Britney Spears, and Barack Obama, had their accounts compromised. The attack was carried out by a hacker who uncovered the credentials of a Twitter support employee, and used those credentials to access other accounts using Twitter ’ s internal support tools. The incident created a lot of concern for the security of the Twitter service, providing more incentive to switch to an authentication scheme that would address Basic authentication ’ s shortcomings and restore user confidence. ___________________________________________________________________________________________________

To be continued…  See article, "What are Data Portability and OAuth?"



Leave a Reply

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