Saturday, June 9, 2012

Lions and Tigers and Bears (Oh My)!

So, this week LinkedIn, eHarmony and Last.FM all had their user password databases hacked. I was potentially affected by the first and by the last. Being married and not overly a fan of eHarmony's working-model, at any rate, I'm not a member of their site.

It used to annoy me when web sites forced you to login with your registered email address rather than your userid. To be honest, I've come to the point where I'd rather they only allowed you to use your email address as your login token. It raises the bar on brute-forcing your account, that way. Not only does an attacker need to guess your password (and I'm generally a fan of four-class pass-phrases), they need to guess your email address, as well (and email addresses tend to be much longer than userids, at any rate).

Granted, if attackers have breached an entire site via the back-end and dumped out the entire user list, they have access to your email address. And, if you use the same email address and password-pair across multiple sites, you're still fairly boned. Fortunately, that's not the case for me. I use unique addresses for each site I register with. So, just because the LinkedIn and Last.FM attackers have my authentication credentials to those two sites, they don't have my credentials to other sites - even if I happened to use the password component across more than one site.

Overall, one of the easiest ways to create unique email addresses is to do a "+TOKEN" email address. Sites like gmail support adding a "+token" to your base email address and still have resultant emails delivered to the base address. As an additional bonus, you can set up delivery-rules to automatically process such emails based on the original target address. Unfortunately, many of the websites I visit consider "ferricoxide+TOKEN@gmail.com" to be an invalid email address. This is just about as annoying as websites that limit me on the password string-length and on the characters I can use. C'mon, guys, this is 2012, not 1992. It's a different security environment out there and you should be doing everything you can to foster good security habits in your users - not hamstring them (this goes double for banks who seem to be the worst offenders with regard to forcing poor userid and password policies).

No comments:

Post a Comment