Month: May 2011

Storing Passwords in the Cloud?

There’s been a recent event at LastPass and users have potentially lost their passwords. Honestly, I wonder why would anyone ever store their passwords anywhere, much less in the Cloud?

Good security practice dictates that passwords should never be stored at all. Period.

While we should use random passwords with different ones for different sites, and it is difficult for users to remember so many meaningless passwords across so many different sites, it is no excuse to store passwords.

IMHO, the ideal solution for this would be to use generated passwords. These passwords could be generated from multiple secrets that are known only to each individual, but not to everyone. Think of it has having different parts of a dollar.

One example would be to use something like password hash, which would generate the password based on the website domain name and a known secret. Try it out and you’ll see.

There are more complex schemes that can be invented if necessary but the idea is there – don’t store the passwords anywhere – generate passwords on-the-fly.

Securing My Blog

In order to improve the security of my blog, I have tried a few measures.

A while ago, I bought a Yubi-Key, which generates a one-time-password to be used alongside the regular login. This provided two-factor authentication and it was certainly working for a while. Then, I read up more about the Yubi-Key and found that there might be holes in the implementation of the plugin since it is still quite a new product and relatively untested.

So, I switched to using VPN instead. I configured my web-server to reject all attempts to access the administrative pages unless the connection originated from the local server. Then, I would use SSH to create a tunnel into the server and secure my connection through SSH keys. This also required two-factor authentication and provided the additional fact that the entire connection was secured over SSH.

I added this to my lighttpd configuration.

# Deny access to wordpress admin pages
$HTTP["host"] =~ "blog.sybreon.com|tech.sybreon.com" {
$HTTP["remoteip"] !~ "213\.229\.116\.90$" {
$HTTP["url"] =~ "^/wp-admin/|^/server-" {
url.access-deny = ("")
}
}
}

However, I had troubles accessing my blog from certain places because they blocked SSH connections.

Finally, I switched to SSL instead. I have now configured my web-server to only accept connections that present a valid security certificate over SSL. Again, this is a two-factor authentication using SSL certificates. Once again, the connection is also secured over SSL. I park my web server behind a pound reverse-proxy. So, this is the way I did it.

ListenHTTP
Address ::
Port 80
## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
xHTTP 0

Service
URL "^(?!/wp-admin).*"
HeadRequire "Host:.*(blog|tech).sybreon.com"
BackEnd
Address ::1
Port 8080
End
End

End

ListenHTTPS
Address ::
Port 443

Cert "/etc/ssl/private/blog.crt"
CAlist "/etc/ssl/private/sybreon.ca.asc"
VerifyList "/etc/ssl/private/sybreon.ca.asc"
Ciphers "HIGH"
ClientCert 2 3

Service
HeadRequire "Host:.*(blog|tech).sybreon.com"
BackEnd
Address ::1
Port 8080
End
End
End

What this does is to reject all connections to the admin pages for my blogs if they came over regular HTTP and to only allow connections over HTTPS. However, for HTTPS connections, client certifications are required, which are signed by a my own custom CA. Otherwise, the connection will fail if a client certificate is not presented.

The advantage of doing it this way is that I can actually have collaborators. All I need to do is to generate new certificates for them and email it to them. This process can even be automated if need be.

PS: You can try accessing the admin page over HTTP and HTTPS here, to see how this works.

Sony EPIC Fail

I just received this in the mail today:

Although we are still investigating the details of this incident, we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network password and login, and PSN online ID. It is also possible that your profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network password security answers may have been obtained. If you have authorized a sub-account for your dependent, the same data with respect to your dependent may have been obtained. If you have provided your credit card data through PlayStation Network, out of an abundance of caution we are advising you that your credit card number (excluding security code) and expiration date may have been obtained.

Wow. Epic fail.

Don’t the programmers at Sony understand the most basic rules about storing personal data? You never store it in the clear. And data for verification purposes should never be stored at all – it should just be HMAC-ed and the fingerprint/hash stored instead.

On my part, I did not store any credit cards with Sony because I have never bought anything from the PSN (and to avoid my nephew accidentally buying anything off the PSN). As for my passwords, I have been practicing new password policies for a while now. So, I think that I should be safe.

While I understand that Sony could just be playing it safe and saying that everything that they store could have been stolen, but this does not help me sleep better at night, knowing that Sony has my data.

No wonder they need to rebuild PSN from the ground up. They are quite screwed. Their new firmware introduced this hole and they cannot patch the consoles through the PSN until the PSN is secure. It’s a security nightmare indeed. Then, they need to re-architect the entire system and restore all the data.

If we thought that the Amazon down-time was bad, this is much worse. Lawsuits!