Irreal

There’s an interesting, if depressing, post over at hover.com about how feedback had fueled new features. One of these new features seems particularly ill-advised. Apparently some of their users weren’t able to remember their passwords so Hover Would send them a special link to reset it, a common and reasonably secure method of handling lost passwords. Unfortunately, the delicate flowers in their user base found this “confusing” and too hard to use. Hover responded by changing the process so that users would be emailed their passwords.

Consider what this means. First, the passwords are being sent in the clear so that there are several opportunities for compromise. Worse, it means that those passwords are not hashed at Hover. Indeed, they explicitly say that the passwords are stored in the clear. There is, I think, a very good chance that the Hover site will be attacked and those passwords and other information exposed. Right after that, the lawsuits will start. Does this make any sense?

Hover provides domain registry and related services so there is something of value to protect. Their Web site makes a point of stressing that they provide Whois privacy to keep contact information private so any lawsuits will surely point to an implied contract to keep this information safe. I just don’t understand what the folks at Hover are thinking. Sure, you want to make things easy for your customers—that’s one of their selling points—but sometimes you need to explain to them why the seemingly complex procedures you use are necessary for their protection. I don’t see how this ends well for Hover.

Over at the AgileBits Blog (the makers of 1Password) Jeff has a nice discussion of picking secure passwords. His discussion is in the context of picking a master password for 1Password but it applies more generally. Much of the really interesting discussion happens in the comments so be sure to read them too.

He emphasizes avoiding predictability while generating long easy to remember passwords. I’m not sure I agree with everything he has to say but there are a lot of good ideas in the post. If you’re looking for ways to generate some high security passwords, this post is a good resource. As I said, there is much wisdom in the comments too.

Two more inductees into the Security Hall of Shame. Honestly, I could devote a whole blog to this sort of thing. Perhaps we should start a Security Hall of Shame blog similar to Steve Friedl’s No Dashes or Spaces Hall of Shame.

The most annoying part of this sorry spectacle is that when these sites are inevitably compromised they will whine about the evil, but brilliant, “hackers” who somehow overcame their defenses when the truth is that they got owned by a bunch of script kiddies. Security is devilishly hard to get right but that’s no excuse for just being stupid about it.

I’ve written before about Dropbox and their supposed scandal regarding the perfectly obvious fact that they could, in fact, read users’ files stored on the site. Despite the lamentations of the aggrieved and even the filing of a complaint with the FTC, I continue to think that those complaining are just being silly or clueless.

Now, sadly, there is a real problem at Dropbox. Earlier this week, Dropbox pushed an update that inadvertently allowed access to any Dropbox account for which the user’s email address was known. This was discovered very rapidly and was fixed within four hours. Nonetheless, the Dropbox logs showed that there was account activity on a small number of the accounts. Yesterday, Dropbox announced that although less than 100 accounts were affected, someone had logged into some accounts and were able to view file and folder names but that no files or account settings were modified and the files did not appear to have been downloaded or viewed.

Obviously Dropbox has egg on their face and, unlike the previous brouhaha, this was a serious failure on their part. There are a couple of obvious lessons that we can take away from this. First, it really is unacceptable for Dropbox to have pushed an insufficiently tested patch to the operational system. To their credit, Dropbox admits this and is not making any excuses.

The second take away is, to my mind, more important. Things like this happen even to the most careful people and users should be asking themselves, “What would it mean to me if it did.” In this case, users should have asked themselves, “What confidential data would I lose if the account were compromised? How devastating would the loss be?” If you’re using Dropbox to sync your college term papers between a laptop and a desktop, then you might be annoyed but you wouldn’t really care. If you’re syncing confidential company plans or sales figures between a laptop and desktop then you might care a lot. Perhaps your company stands to lose substantial amounts of money. Perhaps you’ll get fired.

The point is, each user should make a rudimentary calculation about what a compromise would mean to them and if the answer is other than “Meh” they had better take steps to protect themselves. No one—no one—should feel sorry for the user who whines that he thought Dropbox (or whoever) was going to protect them. If it’s important and you’re going to store it in the cloud, you had better encrypt it yourself.

Fortunately, in the case of Dropbox this is particularly easy to do so there’s no excuse for anyone to have suffered any real harm. But, of course, many people have not protected themselves and they will be mad at Dropbox. Many of them will likely sue; they had better hope that I’m not on the jury.

Update: That didn’t take long.