Marcus Ranum isn't shy about saying logins and passwords are weak and outdated methods too often relied upon for online authentication.
In the wake of the LinkedIn breach, which exposed 6.5 million hashed passwords, Ranum, chief of security for online security provider Tenable Security Inc., says it's obvious the ongoing use of passwords is opening online users and organizations to security risks and breaches.
"This is a place where I have a certain amount of pain. Security practitioners have been saying, literally for decades, that passwords are a problem," Ranum says. "If you're part of an organization that's supporting anything that requires some kind of a password login, honestly, you should be looking at what you can do above and beyond passwords to protect your users against the inevitable time when their passwords are compromised."
Users are starting to jump on the bandwagon as well. An Illinois real estate sales associate, who's been a LinkedIn member since 2010, recently filed a $5 million class action lawsuit against the LinkedIn for failing to adequately encrypt its passwords (see Member Sues LinkedIn for $5 Million over Hack).
LinkedIn says the lawsuit is frivolous, but the action reflects growing concern for any organization that maintains an online presence. When passwords are easy to hack, organizations are vulnerable.
Ranum says organizations can - and should - do more to protect themselves from leaks and lawsuits. Customer education is key.
"It's really not a bad idea if you can have something in place on the password-change page - or the login page - that just tells the user, 'Please don't use the same password you use on Facebook,' or, 'Don't use the same password as you do on your favorite blog,' or whatever," he says. "'Doing so magnifies the likelihood that things can go wrong.'"
When a password breach occurs, Ranum says, organizations that have educated users about adequate password security have stronger legs to stand on. "It's the user's responsibility for not guarding their password efficiently," he says. There's a certain amount of value to being able to say, "I told you this would happen."
During this interview with BankInfoSecurity's Tracy Kitten, Ranum explains:
- The vulnerabilities of hashed passwords;
- Steps organizations can take to secure online passwords; and
- Why organizations have to ensure every entity their sites touch, from vendors to other third parties, are implementing adequate site security controls.
Ranum, since the late 1980s, has designed a number of groundbreaking security products including the DEC SEAL, the TIS firewall toolkit, the Gauntlet firewall and NFR's Network Flight Recorder intrusion detection system. He has been involved in every level of operations of a security product business, from developer, to founder and CEO of NFR. Ranum has served as a consultant to many FORTUNE 500 firms and national governments, as well as serving as a guest lecturer and instructor at numerous high-tech conferences. In 2001, he was awarded the TISC "Clue" award for service to the security community, and also holds the ISSA lifetime achievement award. In 2005 he was awarded Security Professional of the Year by Techno Security Conference.
Hashed Passwords: Vulnerabilities
TRACY KITTEN: What is password hashing and why is it a security problem?
MARCUS RANUM: The problem with the way hashing is done is really fundamental to passwords. It's something you really can't get away with. The hashes are stored instead of actually storing your plain-text password; but the problem is if someone is able to get the hashes, they can do an offline computation, where they essentially compute all of the possible passwords and then they can just look the hash up in this password database, and the password falls out the other side.
KITTEN: What about salted hashes?
RANUM: With a salted hash, you just put some kind of an initializer into your hashing function before you perform the hash, which means instead of being able to simply hash all the passwords and keep those in a database for quick look-up, I'd have to keep all the hashes, plus all the possible salts, which, in theory, becomes an impossibly large number, unless you're extremely well-equipped or very well-funded. But, in practice, if I've got a salted hash, I can still attempt a brute force attack against it. And we're in an era now where GPUs [graphics processing units]and CPUs [central processing units] are fast enough that you actually can, practically, brute force hashes against a single password in a reasonable amount of time.
KITTEN: Beyond LinkedIn, we've seen a number of online sites affected by breaches of hashed password databases. What's the connection among these breaches, if any?
RANUM: It's hard to know if they're connected. Although, when I started hearing about the reports, I was thinking, "Wow, it would be interesting if somebody was doing some research to see how many people use the same password on all these sites?" That would be kind of interesting. But stealing a system, especially a big system that's a social media one, if you can steal their password database, you've got a decent chance of being able to compromise all of an individual's other passwords that you're able to find out about.
For instance, if you know a certain individual tends to use the same username all over the place, and you're able to compromise one of their passwords, that's extremely valuable. You may have their Facebook password or their online banking password. You may not care about their Facebook password, but it goes either way. So, if somebody is using a gaming site, there's a chance that their online banking password is the same as the password they use for the gaming site.
These types of hacks go back quite a ways, and I do suspect that there are people who collect large quantities of passwords, simply because they're looking to try to see if they work on other sites.
Accessing Hashed Passwords
KITTEN: What steps do hackers have to take to attack a hashed password database?
RANUM: There are a couple different ways of doing it. One approach would be to find some way of breaking into the system itself; and if you break into the system itself, you can access the passwords out of the database. I don't think there are that many hosting systems that have access to a password file or something like that. But the original, quintessential password hack was to break into some UNIX box and steal the "etc." password file, which had the password hashes in it, and then you could work on those offline.
Nowadays, especially when you're talking hundreds of thousands and millions of passwords, you're looking for access to password databases, and usually that involves some kind of an SQL database - someplace for the hacker to perform password-hash mapping, and that can be accessed either by breaking into a system and then just doing an SQL call, or sometimes they're accessed through vulnerabilities in software that have access to SQL.
So, if I'm able to do some kind of a Web-based attack against your website, like a SQL injection, which is a very popular way of doing it, and I'm able to successfully inject SQL into the site, if the site is not designed very carefully, sometimes the whole password database is sitting right there, and it's very easy to just pull it right out.
KITTEN: What about storing? Are hashed passwords stored in online databases?
RANUM: Usually it's in some kind of a database, and some people building database systems for large websites are careful about trying to put stored procedures around the database so that you can't "select *" from users; rather, you can only retrieve an individual user account at that time. You can do a bunch of things to try to protect against how the passwords are accessed out of the database, but, ultimately, the software that's making your entire website work is the problem. In order for somebody to be able to login, the website has to be able to check that user's password, which means that the software that makes the website work has to have access to the password database somewhere.
KITTEN: Is the management of those online databases of hashed passwords typically outsourced to a third-party?
RANUM: It's almost always an in-house thing, and that's one of the reasons, again, why this is a problem. There are folks who set up websites and just get it working; they don't re-access whether or not the security of their password system is good. The site, over time, grows, and before you know it you've got a couple hundred thousand users and now, suddenly, it becomes a little difficult to re-engineer the site. I think there are a lot of situations where you see these password leaks, and they may be something that has been coming for a long time, or they may have been accessed multiple times but eventually got discovered.
KITTEN: What the greater, perhaps unspoken of, issues related to exposed passwords - those things we might not consider?
RANUM: I suppose you could impersonate a user, and that's another issue. You've probably seen a couple of things in the press where some Hollywood star's account got compromised; and if the hackers are able to compromise the password, that means they own the account. They can potentially check e-mail and stuff like that for a long time. I think that's kind of the primary danger. Obviously, if somebody's able to get access to somebody's online financial information, they're going to monetize it, which I guess is a nice way of saying "steal it."
It's surprising. There are very clever people who are thinking about ways to steal from people all the time, and they're remarkably creative. You might have something that you don't think is particularly valuable, but somebody can figure out a way of making money from it. Take your frequent flyer miles award password, as an example. That password is valuable for buying plane tickets, and hackers could use it to buy tickets for their friends. Or, they could take something else sell it at an auction online, or something like that.
Securing Online Passwords
KITTEN: So how can organizations ensure their online password databases, hashed or not, are secure?
RANUM: This is a place where I have a certain amount of pain. Security practitioners have been saying, literally for decades, that passwords are a problem. What's really extended the semi-useful lifespan of passwords is the wide-scale adoption of encryption and SSL [secure sockets layer]. So, suddenly, passwords weren't something you could just snip off the wire. You had to go to greater lengths, like doing a smash-and-grab against the password database.
But if you're part of an organization that's supporting anything that requires some kind of a password login, honestly, you should be looking at what you can do above and beyond passwords to protect your users against the inevitable time when their passwords are compromised, either through your site, which you hope doesn't happen, or through somebody else's.
The kinds of things that you can do include looking at whether there are protections you can put in place to prevent passwords from being as damaging, if they are compromised, or detect quickly when they have been compromised. Then, of course, the best thing you can do is to try to tie authentication to some kind of a secondary device that has also been authenticated.
KITTEN: What about vendor management? How can organizations ensure the vendors they work with are taking the necessary precautions to protect online passwords and databases that house hashed passwords?
RANUM: Honestly, I think you should probably assume, if you're using passwords, that they're going to get disclosed. I know that's not a popular view, but that's the one that I've been operating under. Passwords are just a bad technology, and they're just a bad idea. The reason everybody uses them is because they're very convenient and they're fairly inexpensive, although getting your account compromised and having to deal with that is not exactly what I would call "cheap."
You need to tell people that they should not use the same password on multiple sites. Again, it's very unpopular to try to enforce good password controls. That's one of the other interesting pieces of research that we get every time one of these password databases gets leaked. We just find out how bad people's passwords are. "I hate my job," for instance, is a very popular password, apparently, on some of the job sites; go figure. So, you have to consider how hard is it to guess this kind of stuff.
I think organizations should be asking themselves, if they're using passwords and they have large password databases, "Is there any kind of a third-factor authentication that we can use, and is there any way we can lock our system down so that it's a little bit harder for somebody to be completely destroyed if something goes wrong?" What I mean by that is, if I'm purchasing stuff from an online store, it might be appropriate to somehow have a check in place, so that if I'm trying to ship it to some place other than my address of record or my billing address, it need to validate that I'm me. It might even validate me using some kind of additional home mechanism, like sending an SMS to my phone and saying, "Did you really just buy 16 iBooks and MacBook Pros and request them to be sent to an address in Canada?" That kind of a question is really important. But you have to think of how to can ask that question without getting the users disgusted. Businesses have a really serious problem here, because our users expect us to do something that really is, basically, stupid; but they're going to blame us when it blows up in their face.
Common Password Mistakes
KITTEN: When it comes to password protection and even protecting login credentials, what are the most common mistakes?
RANUM: The most common mistake is to have some kind of a SQL injection attack on whatever your application is. Unfortunately, that one's pretty shockingly common. I don't do Web-code assessments, because mostly I'm pretty ignorant about the programming languages a lot of this Web stuff is written in; but my friends who do assessments of websites are generally pretty disappointed in the quality of the software. There's a tremendous amount of stuff that seems to work when they implement the software, and then they go live with it. One of the things that an organization definitely should be doing is looking at doing some kind of an assessment of the quality of the software they've developed; unfortunately, it also applies if it's software that they got from somebody else. They really should do their research and find out if that's a piece of software that has had a history of problems. It hardly takes anything to exploit a SQL injection attack. It's one of the most popular attacks going on in the Internet, and it's popular because it works. The most pernicious thing about it is that it's incredibly specific to a particular site.
If I have a SQL injection attack, it's going to be different from yours, so there's not really a way that a firewall vendor or somebody like that can come along and try to do a blanket solution for it.
Every organization that's doing anything where they've got a password database really needs to look not simply at the pieces of their application that are accessing the password database; you need to worry about everything. It's easy to see how the classic SQL injection attack works. Just got to the top of a webpage you login to. When I visit a common webpage, I'll see "Welcome MJR" at the top, so the page can figure out my username. The problem is that webpage probably also has access to the password database. So, if the system wants to put Marcus Ranum at the top instead of MJR, then the password database is going to have not just my login name, but my full name and my password hash. Somebody who's doing an assessment will look at the front page, and if that person sees the page doing the username, you know it's probably accessing the password database. That also means that if there's any place, like an input field for anything that comes from a user correctly, there is a way to squeak some SQL in there; the page is actually going to get evaluated, instead of used as part of a query. From there, I can just put the equivalent of "semicolon, select *" from the users or drop tables.
Immediate Steps to Respond
KITTEN: So, we know passwords are antiquated and inherently insecure. But we're going to have to live with them for a while, I think we all agree. So, what steps, Marcus, can organizations immediately take to make their passwords more protected?
RANUM: If you're part of an organization that's doing something that really is financially sensitive, it's really not a bad idea if you can have something in place on the password-change page - or the login page - that just tells the user, "Please don't use the same password you use on Facebook," or, "Don't use the same password as you do on your favorite blog," or whatever. 'Doing so magnifies the likelihood that things can go wrong.'
Another reason you want to do that is to educate the users about who's responsible in the event that there's a failure of password control. Obviously, if an organization leaks all of the users' passwords, they're in trouble. But if some other organization leaks all the users' passwords and somebody uses their legitimate password to get into your site and do something that costs a lot of money, whose responsibility is that? It's the other site's fault that the data was leaked, but it's the user's responsibility for not guarding their password efficiently. That's an issue. You want to make sure you can get as much mileage as you possibly can out of educating the users about their rights and responsibilities, and what they can do to help protect themselves.
Then, honestly, I would recommend to any organization that they look strongly at using some kind of a third-party authenticator. I was at a conference last month and I asked the approximately 1,200 people that were in the room, "How many of you use the Google cell phone authentication system?" I was the only person in the room who did, and this was a conference of computer security practitioners. I was mortified. There are lots of other systems that work, and there are commercial offerings that enforce this sort of thing as well. It's pretty nice. Once a month, when I go to login or use one of the services, instead of getting whatever page it was that I going to, I get a message that says, "Enter the code that we just texted to your cell phone," and my cell phone beeps and I enter the code. Then I have access for a month.
What they've done is tied the fact that I'm the holder of the phone to the fact that I'm the holder of the account, and the premise of that is pretty good. It's really hard to steal my cell phone over the Internet. You've raised the bar very, very high by doing that kind of thing.
But the big problem here is the users, because they really grumble and complain when you try to get them to do anything other than just store all their passwords in a single online password wallet. Then, when it automatically gets stolen by the browser, they wonder why their stock account got pumped and dumped. Explaining that kind of thing to users up-front is very important. There's a certain amount of value to being able to say, "I told you this would happen."