Circumventing Password Authentication

Description of the Problem

Many sites initially require a username and password to authenticate the user. However, in the future, the cookie is the only token needed. Often these cookies are easily forged or guessed by an interrogative adversary.

ihateshopping.net - the id used was a serially assigned integer unique to the user which is used to authenticate the user's requests for the remainder of the session. Since the namespace of ID cookies is densely populated, an adversary can can access to arbitrary accounts.
New England Bride(nebride.com) - A user logs in with a username and password, but receives a cookie which is simply a username. If an adversary can guess the username of an existing account on the server he/she can have access to that account.
highschoolalumni.com - In this case the information in the cookie is the username and UID both of which are available to any user in their public database on the web.

Example:

New England Bride (www.nebride.com) uses a cookie called ID to verify its users. The value of the cookie is the user's id (in plaintext). Create an ID cookie with your ex-girlfriend's username as the value, set your URL to http://www.nebride.com/pages/neb/sys/asp/changereginfo.asp , and you have instant access to her name, address, phone number, e-mail address, wedding date and place, and password -- interesting how many of these bear a startling resemblance to the groom's name -- that's right, it comes up on the screen in the clear. In addition, if she's using the services provided, you can have access to (and alter) her guest list and the list of support services (caterers, etc.) she's using.

Solutions

Use authenticators which are not easily predictable or guessable.

List of Sites who have suffered this problem

[Home] [Publications] [Cookie encyclopedia] [Mailing list] [FAQ] [Contact us]

Join the Blue Ribbon Online Free Speech Campaign!