If you’ve been keeping up with computer security breaches, read popular press or watched TV news, you’ll remember that hackers stole some data from the Ashley Madison site. Their clients are worried their emails might have been exposed. For the record, I’m not a client.
When I was preparing to write about the breach I came across a blog post with the title “Your affairs were never discreet – Ashley Madison always disclosed customer identities”. I expected the post to be about some issue in Ashley Madison’s Terms of Service or some such. No, the post was about information leakage. It seems that if you tried to reset a password for a particular email address at Ashley Madison, their web page responded differently depending on whether the email address was registered there or not.
That means the site made it clear whether or not a given email address belonged to one of their registered users. That is, the site leaked that information. To be fair to the clients of the site, they probably didn’t use their primary email address for their accounts there – or maybe they did, who am I to guess?
Anyway, the point here is that incorrect error messages can leak information. Consider a web login window: after entering an incorrect username/password combination, it could say either “Incorrect username/password” or “Incorrect password for username” or “user unknown” or some other message. Only the first one doesn’t leak information. We’ve probably all seen these messages on the web or on software packages and seldom thought of them. We recognize the error and try again.
There are more blatant cases of information leakage such as using unencrypted WiFi, but today I’m addressing more subtle forms. Information leakage is the unintentional disclosure of information otherwise intended to be confidential.
Another source of “subtle” information leakage is the error message. Sometimes, developers design error messages to be helpful to themselves – that’s good for the developer. But, when a system goes into production, messages that include database tables names, SQL queries, URLs, HTML POSTed information, stack traces and so forth expose sensitive information to the public and potential hackers.
Another example of information leakage can lead to traffic analysis. Consider Alice and Bob. Normally they communicate with each other over unencrypted email, but then they send a flurry of emails between each other that is encrypted. An observer can see that something unusual is going on that Alice and Bob want to keep confidential. It may be a financial deal or something else. If they had used encryption in all their communications, the observer would not have known about the “specialness” of some of the messages. In Learning Tree’s System and Network Security Introduction we talk about this kind of traffic analysis and urge parties to encrypt all communications for this reason.
To your safe computing,