Last time, I lamented the sparse deployment of SSL on the web. SSL for static, and public pages is useful. However, it’s value skyrockets when dealing with user authentication, and users’ private data. However, many web sites misuse SSL in a variety of ways, and perform user authentication badly. Depending on the sort of interaction that a user has with the site, and the sort of private data that they store there, the risks can range from mild severe.
Today I depict a potentially problematic scenario that can arise from poor user authentication. Next time, I’ll talk about the design assumptions and errors that give rise to these risks, and what sort of steps we can take to mitigate these problems.
When a a user accesses their email over the web, they expect a high degree of privacy. Phrases such as “reasonable expectation of privacy” are legal terms of art with very particular technical meanings. However, I use it here as in plain language. The user thinks that nobody will be able to access their email; they think that their messages will be seen only by the intended recipient(s), and nobody else. The same is true of social networking sites with privacy systems: when a user sends a “private” message, they anticipate that it will only be seen by the recipient.
Sadly, this is not always the case. Facebook, for instance – while supporting SSL – does not use it by default, even for user authentication. This has the undesirable effect that any malicious eavesdropper can passively see everything that a facebook user sees or posts. Worse still, since the sign-in page does not use SSL by default, an eavesdropper can see a user’s email address and password whenever they sign in. The attacker can now log into the user’s facebook account, and read all their data, not just that which they looked at this session. The attacker can even impersonate the user.
However, thanks to certain characteristics of web authentication, the problem doesn’t stop there. Most websites use very similar authentication procedures: the ubiquitous email/password prompts. Users, it must be said, do not vary their passwords much from service to service. Some say that this is rational behaviour by users. Either way, compromising a user’s credentials for one service makes it eminently likely that you have their credentials for a variety of other services.
More importantly, using an email address as a user’s unique identifier means that an eavesdropping attacker can make a very good guess what their email provider is. If the eavesdropped password is the same as the user’s email password, the attacker has access to the user’s email. The universal practice of email confirmation messages means that the attacker can probably determine all the other services that the user uses. Email password resets give the attacker access to those accounts. Suddenly the user’s entire online life is accessible to the attacker, just though an insecure Facebook login.
Of course Facebook is not the only culprit. Many sites use an insecure (not SSL) login page, and request a typical username/password combination. However, the high ubiquity of Facebook accounts makes it an attractive target.
The problem here is a combination of factors. The de-facto use of email address and a single password as a global identifier means that the weakest authentication system breaks a user’s security for all services. That users and sites are happy to use insecure authentication makes this attack possible for most users. The use of email as a central point of control and management makes it easy to go from one account to many.
Tune in next time when I’ll talk about the poor design assumptions that lead to this house-of-cards security, and what we can do about them