Linked In LEAKED HASHES

The security professional in myself wants to believe that recent Living Social breach is teaching us all one thing — our credentials on any web site are very vulnerable. If Bob Smith can get my Facebook credentials, he sure as hell better not be able to log into my bank or my email account. So, we’re all making sure we don’t reuse passwords, and better yet, usernames, on any of the tens (hundreds?) of websites we create logins for, correct?

Err, no. Chances are your grandmother (and let’s face it, probably you) are reusing the same username, email, and password somewhere on the web. Maybe it’s just some throwaway account you reuse when you need to make a one-off order on sites like Paul’s Peanut Brittle dot com. The truth is that only one in a million users are sophisticated (and patient) enough to use a password manager for each login they create, and most people don’t care. They’ll sacrifice security for ease of use every time. They’ll reuse the name of their dog plus their birthday for the password willy-nilly: for their bank, their TurboTax account, for their Pinterest login.

So what’s a person to do?

The credentials issue is a hard one to solve. As developers, we don’t want our users to be vulnerable, and futhermore, we feel a responsibility to make sure we protect a user’s information — even if we are curators of a social network for dogs, that login information is gold. We can’t enforce uniqueness in terms of passwords for users. If they are going to use their bank password for mydogfriends.com, so be it. Two-factor is incredibly frustrating for most users, so often that’s out of the picture. The promise of single-sign on with OAuth/OpenID may whittle down the having-to- keep-track-of-thousands-of-logins issue and offload the authentication to someone else, but if your user’s Twitter account gets compromised it very quickly becomes a single source of failure. We can make sure we use bcrypt and other modern hashing mechanisms so that if a database dump is grabbed, it can’t be cracked by a dude with a script and ten EC2 servers at his disposal. Nevermind that if someone has access to your box on any serious level, they can probably sit there quietly and glean passwords from your network traffic or even process memory.

Ugh, so what’s a person really to do?

If we assume that someone out there, at some point in the future, will be able to get access to any web app we have credentials, then the next best thing to preventing them from logging in the first place is knowing about it when it happens.

Unfortunately, standards for auditing hasn’t reached the same level of maturity that, say, standards for authentication have. We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events. Since authentication events are relatively similar across any application, I think this could be accomplished easily with a simple JSON-based common protocol and webhooks.

Here’s how it could work. I provide a unique webhook url, say, https://myaudithooks.com/xjt43wafd, that I plug into my account settings for http://www.mydogfriends.com as my audit provider webhook. Whenever I log into mydogsfriends.com, it posts a login event to https://myaudithooks.com/xjt43wafd that contains my IP address and other information: time of login, geo IP information etc. If I owned myaudithooks.com, I could have it email me based on certain rules.

Better yet, myaudithooks.com could even be a hosted service that learns based on my login behaviors and only alerts me when it thinks a login entry is suspicious— kind of how Gmail will alert if I am logging in from a strange location. Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won’t have access to alter its audit log history since it lives somewhere else.

It seems like such a trival thing, but imagine if Facebook, LinkedIn, and all of the major web apps you used provided such functionality. I’d be able to sleep a little easier knowing that if one of my account credentials were compromised — whether it be due to my own carelessness or that of a random developer’s — I’d have a nice history and potentially even alerting so I know about it when it happens.