Patrick Lambert looks at the rash of stolen password exploits and how websites are trying to move beyond passwords only as a security check.
We've talked a lot about passwords. In fact, they have been in the news like crazy in the past couple of weeks. First there was the LinkedIn incident, where over 6 million LinkedIn account names and unsalted SHA1 passwords were released. The fact that they were unsalted meant that it was trivial for hackers to recover all of the basic ones, and because they were hashed using SHA1, it meant that most nine-character or less passwords could be cracked inside of a few hours. Then, we saw the same story repeat itself for various other companies like Last.fm and the popular matching site eHarmony. In each case, we see what happens when a hacker manages to get a hold of one of the most sensitive databases a company can hold on behalf of its users -- the account names and passwords. And these are fairly large sites, so it really can happen to anyone. When a user doesn't lose their account credentials because of malware or brute force, they never know when they will lose them because the company itself gets exploited by a security vulnerability. That's why many security experts have been pushing companies and sites to move beyond simple passwords.
Let's face it, user names and passwords are a crappy way to deal with account security. We're basically relying on having every single user to remember an obscure series of numbers and letters in order to log in. There are so many potential problems with this, that it's no surprise we've had so many breaches in the past years. Users can forget their passwords, which means all sites need a password recovery link; these passwords may be weak, which means they can be brute forced; and any time the secret string gets out in the wild, then it's too late, and users are left scrambling to change their passwords before their accounts are exploited for some nefarious reason. And even sites that think they are doing everything right can be wrong, because the bad guys always go for the weak link, and all they need is one hole to enter, whether that's exploiting a weak password recovery tool, finding a way to place malware on users' computers with phishing attacks, or finding a weak point of entry into the company network, and then stealing the master database. So it's clear that the time has come to move to other models.
Rely on a third-party
One model is to use a third-party authentication service. A lot of sites don't even want to bother with accounts, along with all the hassle of keeping local security around their password databases; instead, they rely on things like Facebook or Twitter logins. This has a number of advantages like relying on a much bigger, most likely more secure site to deal with security, and offering the user the option to log in without having to create a new user account for your site. Of course, there's also a big disadvantage in that you don't control those accounts, and you rely completely on that third-party company. While they are happy to provide you the service, they could cut you off at any time, and aren't responsible for any breach. While this is a convenience that many sites adopt, from a security standpoint. it's debatable whether the benefits outweigh the disadvantages.
Instead, a much more secure way to deal with passwords is to add a two-factor authentication system. Perhaps the most well known is Google, which implemented its own system just a few years ago. Now, a lot of sites are using the same model, where they provide either a physical token or a smartphone app, and users simply produce a new token any time they want to log in. Of course, it is a bit more inconvenient for users, but as most security researchers know, security and convenience are usually opposites. Here, the benefits of having a two-factor authentication system are very clear: nobody can get into your account by obtaining your password, unless they also somehow manage to get your phone. While you may think that for a smaller site it's not worth creating a whole token or smartphone app, it's actually much simpler than that. Most people don't realize that the Google Authenticator, an app available for all major smartphones, is using fully open source code, and allows anyone to add identification tokens. There is demo code out there showing that it's possible to make your own two-factor authentication login system using the Google Authenticator in just a few minutes.
Of course, like anything else in security, don't assume that any one system is fully secure and you will never have to worry again about it. Just recently, someone actually found a way to bypass Google two-factor authentication to get into a company. As a company executive explained, it seems like the hacker went after the phone company in order to redirect the voice mail of the administrator to his own number, so that he could get Google to send him an authentication code, and the real administrator wouldn't be aware of it. So again, while the Google system was fine, because AT&T got socially-engineered by the hacker, that was the one weak point in the chain, and everything else came crashing down around it. So like anything else, it's always a matter of using the best methods you can, without inconveniencing your users too much. There's no question that two-factor authentication is a good system to use, but remaining always vigilant with sound auditing policies, intrusion detection systems, well stored salted passwords, and trained staff, is also crucial.
Are we stuck with passwords for the foreseeable future or do you expect to see more advanced methods of authentication rolled out?