This past week, several users reported visiting Facebook, and, well, seeing the wrong face. Without any action on their part, a number of AT&T smartphone users found themselves logged into the popular social networking site under user accounts other than their own.

The problem was quickly attributed to "misrouting," a term that suggests that information took a wrong turn somewhere in the network. It's not completely impossible for individual packets flying across the network to be misdelivered—although there are multiple checksums protecting against that—but misdelivered packets will be uninvited guests at the destination computer, and thus thrown away. What apparently happened here was an unfortunate interaction of some kind between Facebook's user authentication system and the way AT&T runs its mobile data network.

The Web actually has a fairly robust system for user authentication, but nobody uses it. With standard Web authentication, the server "challenges" the client, and the client responds to the cryptographic challenge based on a shared password. If the response to the challenge is incorrect, the user sees an error page. Such a system is robust and secure, but it's also not very user-friendly, because browsers throw a big username/password requester on the screen before the site loads. To avoid this, 99 percent of all sites implement user authentication themselves. There are two problems with this. First, putting a password in a normal text box means it's transmitted in the clear. To avoid this, it's necessary to use an encrypted HTTPS session, at least to transmit the password. Some sites do this, others simply send it in the clear where it can be intercepted relatively easily, especially—but not exclusively—on unencrypted Wi-Fi networks, such as Wi-Fi hotspots.

The second problem with home-grown user authentication is that it really only secures a single page. If the user later loads the page again, or loads another page, she would have to type the password again to really be secure. The solution to this problem is for the server to store some information in the form of a "cookie" on the user's system. Cookies for a certain site are automatically transmitted along with every HTTP request made to that site, so the server can recognize the user by the information in the cookie. So far so good. (Ignoring the fact that cookies can also easily be intercepted if sessions are unencrypted.)

When mobile phones first gained the ability to access the Web, a lot of work was done to optimize the experience on slow, memory-starved devices with a slow connection. Much of that magic involves Web proxies. One way for this particular Facebook user authentication issue to come up on AT&T's mobile network would be if there is a caching proxy in between the server and the user that doesn't pay attention to cookies. So if user A with cookie X visits Facebook, the proxy caches the page user A gets. Then, when user B comes along with cookie Y, the proxy simply sends the cached page to user B, which is of course the page that only user A is supposed to see.

Another possibility is that AT&T uses proxy cookies. WAP, a protocol that was used to create a Web-like experience for phones not capable enough to show the real Web, doesn't support cookies. This makes life hard, so proxies that let WAP clients talk to Web servers often implement "proxy cookies," where the proxy stores the cookies on behalf of the client. However, in that case it's essential that the proxy knows which user it's proxying for at any given moment, otherwise it sends the wrong cookie to the server and the user is logged in as someone else.

So it looks like AT&T did something wrong—even though I wouldn't call it a "routing" problem—and the company is in the process of fixing things. But Facebook also shares some blame for this situation. Apparently Facebook, like many other sites, doesn't think the information tied to a user's account is important enough to protect with something stronger than a clear text cookie. Encrypting all sessions would solve these problems: passwords and cookies can't be intercepted and proxies can't get to the data. Personally, I like the way Amazon handles this situation. When I arrive at Amazon.com, they recognize me and spam their recommendations at me, but when I actually want to order something I'm redirected to the encrypted site and I have to type my password. Also, Amazon explicitly recognizes that it may have mis-recognized me and offers a link to solve the problem.

Further reading: