Irreal

Troy Hunt has a nice post on SSL and how many sites misuse it. As Hunt says, SSL is not about encryption. The problem that Hunt is writing about is sites that deliver a login page, say, in http and then post the login credentials over https. The idea is that the credentials are sent encrypted so everything is nice and secure. Often these sites will even display a padlock icon suggesting that the login is secure.

The problem, as Hunt explains in detail, is that the user has no way of knowing to whom those encrypted credentials are being sent. With SSL, the user is assured¹ that the login screen is from the site it’s purported to be representing. If the login screen is not sent by SSL (indicated by an https connection) then the user has no way of knowing where it came from or where the login credentials will be sent once the user enters them.

Hunt gives real examples of governments exploiting this vulnerability so we’re not talking about a theoretical threat. Sadly, many sites continue to get this wrong putting their users at risk. That authoritarian governments are exploiting it means that it can literally be a matter of life and death. Remarkably, when Google moved Gmail to SSL the increase in load was within 1% of existing load so there really is no excuse for not using SSL at least for logins.

This is a great post and very informative. If you are developing Web sites, you definitely need to know this material. Hunt’s post is a great way to get started.

Much is being made of the supposed Dropbox break in. Several users reported that they started receiving spam at email addresses that were only used with their Dropbox accounts. Dropbox, to their credit, immediately launched an investigation and brought in outside investigators to aid in their analysis.

The results of that investigation pretty much boil down to:

• Most of the accounts were compromised because users had used the same passwords at other sites that were later compromised, and
• A Dropbox employee, whose account was compromised in the same way, had stored an internal Dropbox document in the system that contained further email addresses.

The press, of course, was quick to compare this to the LinkedIn exploit that resulted from very poor security practices on LinkedIn’s part. But how, exactly, is Dropbox to blame for this? Yes, they have an employee who did an extremely stupid thing but how are they supposed to guard against users reusing their credentials? All in all, Dropbox was taking security seriously and doing everything right. They have since started offering optional two-factor authentication and a page that allows users to track logins to their accounts.

To my mind, the real blame belongs with the users who couldn’t be bothered to use unique passwords. This does include the Dropbox employee who, one hopes, had been admonished, terminated, or otherwise suffered the application of the clue bat. As I wrote recently, password reuse is endemic and those who are guilty of it deserve no sympathy when the real world exacts its revenge.

And, by the way, let me say again: if you store sensitive data in the cloud you better encrypt it. Dropbox is, of course, responsible for the action of their employees and one hopes that this incident will encourage them to make sure these employees aren’t doing things that endanger their customers. Still, the user is ultimately responsible for safeguarding their data. That means that they should assume that screw ups will happen and should therefore take actions to ensure they aren’t affected when they do.