Password management failures

As it happens, today’s news seem to cover a new skirmish in what some people seem to have exaggerated into calling an “infowar”; after the repeated DDoS – repercussions of which I’m sure we’ll e able to see in a matter of months – the prey this time has been the “A-list blog” Gawker and the results, well, are kinda sad.

You can see a basic report on The Next Web but the more interesting reading is the post on Forbes by Daniel Kennedy that goes into detail of what kind of technical failures there have been with Gawker’s security process.

What really baffles me is how is it possible for anybody to still store password in anything but properly salted hashes. Hey guys, we’re in 2010 now, most of your infrastructure is outsource and is thus available to a number of people beside your intimate administrators, even if you didn’t incite a group of hackers to attack your system!

Interestingly, in all this, the centralised password storage approach seem to actually come out pretty nice: Facebook Connect users who used that to comment on Gawker were safe because their password never left the Facebook infrastructure (and as much as you can say about it, I’d be surprised if they didn’t have a better password storage than that!). So this time I can safely say that they got out of the glorified phonebook that I have considered it in the past few years (which actually is quite an interesting approach when you have an Android phone that syncs the local phonebook with Facebook: having the person’s unique chosen photo appear is faster than reading the name).

At any rate, it happens that a lot of web application and systems still send your password back in cleartext of email when yo ask for a reminder, rather than sending you a one-time token to reset it (or cancel the reset altogether). A week or two a go a friend of mine, who’s not as security savvy as me, had his GMail account compromised; as me and most other GMail users, if it’s not spam, the mail is never deleted, and since he’s not that much into security, he didn’t get into much trouble to delete the password reminders or registration confirmation, so I suggested him to search on his own for “your password” and variations, and change the passwords for all the services that ever sent him an email like that — after changing the password to GMail itself, as well. There were a ton.

Interestingly enough, if I search for “your password” on my GMail account (that uses the strongest password I can remember easily, and yet it’s unique just like root password on my vservers – users are not allowed with password at all, root is only allowed for su – and the passwords for most webservices, even if “blander”), I also get some hits. And yes I tend to be careful with these things; of course only two are actually recent enough to matter: one is the registration to Telltale Games and the other … Java.net password — I’ll be back soon at this. The latest instance that I can remember of a service sending me my own password by mail in cleartext has been an Italian webshop (and what’s up with the URL? never mind).

Back to the Java.net case. If you remember is not the first time I write about passwords and last time I also noted one thing: do not just change my password. Now in this case the situation is a bit more complex: when Oracle acquired Sun, one of the things that made sense to do was definitely the merge of infrastructure (as an outsider, that looked a lot like resource waste; on the other hand, an interview to Scott McNealy can easily point out the underlying cause: factions within the company). This also meant they had to restructure the accounts, which meant a new java.net password. This is probably one of the few cases where you can reset user passwords and send them a (one-time!) password on your own.

Finally, a bit of a reflection: when will browsers start supporting client-side certificates well enough that one can actually start using those as a first-class citizen in the webservice landscape? Although I admit I have never looked into whether Rails make it easy to deal with client-side certificates for login. Any suggestion on the matter would definitely be interesting.

Hunting for a SSL certificate

So, in the previous chapter of my personal current odyssey I noted that I was looking into SSL certificates; last time I wrote something about it I was looking into using CACert to provide a few certificates around. But CACert has one nasty issue for me: not only it’s not supported out of the box by any browser, but also I have failed up to now to find a way to get Chromium (my browser of choice) to accept it, which doesn’t make it better than the self-signed certificates for most of my aims.

Now, back at that time, Owen suggested me to look into StartSSL which is supported out of the box by most if not all the drivers out there, and supports free Class 1 certificates. Unfortunately Class 1 certificates don’t allow for SNI or wildcard certificates, which I would have liked to have, as I have a number of vhosts on this server. On the other hand, the Class 2 (which does provide that kind of information) has an affordable price ($50), so I wouldn’t have minded confirming my personal details to achieve that. The problem is that to get the validation, I need to send a scan of two IDs with a photo, and I only got one. I guess I’ll finally have to get a passport.

As a positive note for them, StartSSL actually replied to my tweet-rant suggesting I could use my birth certificate as secondary ID for validation. I guess this is easier to procure in the United States – at least judging from the kind of reverence Americans have of them – here I’d sincerely like to not bother going to look for it, especially because, as it is, my birth certificate does not report my full name directly (I legally changed it a few years ago if you remember), but as an amendment.

There are, though, a few other problems that shown up while using StartSSL; the first problem is that it doesn’t allow you to use Chrome (or Chromium) to handle registration because of troubles with client-side certificates. Another problem is that the verification for domain access is not based on the DNS hosting, but just on mail addresses: you verify the domain foo by receiving an email directed to webmaster@foo (or other email addresses, both standard and taken from the domain’s WhoIs record). While it’s relatively secure, it only works if the domain can receive email, and only seem to work to verify second level domains.

Using the kind of verification that Google uses to verify domains would make it much nicer to verify domain ownership, and works with subdomains as well as domains that lack email entirely. For those who don’t know how the Google domain verification works, they provide you with the name of a CNAME you have to add to your domain and point it to “google.com”; since the CNAME they tell you to set up is created with a hash of your account name and the domain itself, they can ensure that you have access to the domain configuration and thus to the domain itself. I guess the problem here is just that it takes much more time for DNS to propagate than it takes an email to arrive, and have a fast way to create a new certificate is definitely a good thing of StartSSL.

At any rate, I got a couple of certificates this way, so I finally don’t get Chrome’s warnings because of invalid certificates when I access this computer’s Transmission web interface (which I secure through an Apache reverse proxy). And I also took the time to finally secure xine’s Bugzilla with an SSL connection and certificate.

Thanks Owen, thanks StartSSL!