Security expert Chris Wysopal explains why the L0phtCrack password cracking tool is being unveiled once again after Symantec discontinued sales of L0phtCrack in 2006. The tool was developed by the L0pht, a Boston-based security research firm founded by Wysopal and fellow researcher Peiter Zatko. Wysopal announced the tool's re-release at SOURCE Boston 2009. Wysopal is interviewed by Michael S. Mimoso of Information Security magazine.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact firstname.lastname@example.org.
Interviewer: This week here at SOURCE Boston, you and some of your former at state colleagues, some guys from the L0pht, you're making some news, you've reacquired L0phtCrack. Can you take me a little bit into that back story? When did this happen, and what was your motivation on your end?
Chris Wysopal: L0phtCrack was something that I wrote with Christien Rioux and Peiter Zatko at the L0pht back in the late 90s. We originally wrote it because it was a proof of concept. It was to demonstrate a vulnerability. Just saying, "I've looked at your password hash algorithm, and I don't think it's secure," doesn't go anywhere. People want to see demonstration. This is another one of my bugaboos of the computer industry: We don't listen to reason, we don't like theory, we want to see a demonstration. I can understand that to some degree.
Microsoft, at the time, was saying, "No, our passwords are secure, we use all of these secure algorithms," but they made all of these mistakes in the way they implemented it. It's always the devil's in the details. Basically, L0phtCrack started as a proof of concept, saying, "This demonstrates that the passwords are weak. You're storing them in a bad way." People just started actually using it, not just as the proof of concept to Microsoft, or to their employer that, "Maybe we shouldn't be storing our passwords in here." They actually started to use it as a security tool.
We didn't really realize this at first. People used it both on penetration tests, as an attack tool to demonstrate that they could get into an organization, and the people also thought, and this is probably the reaction to that, "Well, if the attackers are going to use it, I better use it on myself and make sure my passwords aren't crackable." So we saw that it had both this attack tool and audit capability, and that had value. We said, "Okay, so why don't we come out with a more commercial version that has a user interface, this documentation, and we'll sell it?"
It was much more successful than we ever imagined. I think it was because, one of the things that L0phtCrack did was, there was a whole bunch of little tools and a whole bunch of knowledge out there, and we put it all in one place. It wasn't like I was running one tool to extract my passwords, or another tool to sniff on the network, and then I run another tool to change the format, and then I run the right password cracker on it, which is how a lot of security tools are. You have to know how to string all of these little things together.
We took all of that, and we said, "Okay, well, let's make something that is targeted at a system administrator." The attacker can string all of the tools together, but the system administrator probably doesn't have the time to do that. That's what I think made L0phtCrack successful: we gave the system administrator the same benefit that the attackers had. We thought it was a good idea at the time to divest ourselves of it, and we sold the tool to @stake, and @stake rebranded it LC. They didn't want to have the word "L0pht" or "crack" in it, those were both two bad things. The people who knew it was L0phtCrack knew LC was L0phtCrack, but not the people who had never heard of the L0pht, or why cracking is sometimes a good thing.
So, @stake sold it, and that was fine. It was good to see them put energy into making it better, and more features, and better documentation, and better looking feel, and all of those things. Then, when @stake got bought by Symantec, Symantec decided, not that it wasn't selling, but it really doesn't fit into Symantec's product line. They really don't have anything in that category. They decided to end-of-life it. This was sort of our baby, our hard work, and it was out of our hands at @stake, but at least we saw that it was in good hands, and it was being taken care of and enhanced. When it was end-of-lifed, it was kind of a sad day.
We went back and we said, "Is there anything we can do to reacquire this?" We went through that process; it took about a year to get through it. It's difficult dealing with big companies sometimes, and I'm sure they're distracted with all kinds of other problems. We got the rights to the technology back, and we haven't actually had it very long, just a month or so. First order of business was to just update it, because it had been off of the market for a couple of years.
One of the critical things with testing the password strength of an operating system is to keep up-to-date with the latest operating systems. It didn't work with Vista, it didn't work with XP 64, or any of the Windows servers that you can run in a 64-bit mode. The first order of business was just to bring it up to date, then get it out there on the market again as quick as possible, being compatible with the latest operating system. You're not going to see a lot of new, great, wiz bang features.
I also think that, on the other hand, auditing passwords has gotten a little bit stale. It's been sort of commodity, people using really old versions, and there hasn't been a lot of new ideas. We have some ideas to bring to the mix. One of the ones is, people say, "Is password cracking even relevant, because now there's the password filter functionality," which puts a constraint on the password that you put in, ostensibly to say that it's got to be complex. If the user puts in a complex password, why do I need to crack it, because I've guaranteed, when it gets input, that it's complex, so I don't have to bother cracking it.
Of course, the devil's in the details again. Is your complexity check, is it a true complexity check, or is it a constraint? The truth of the matter is, they're not really complexity checks, they're constraints. For instance, I could say, "You're not allowed to have a dictionary word in the password." Well, an easy way to do that is, so you don't have to keep huge word lists around and test against a word list each time, instead of doing that, which would be the way to check that you don't have a dictionary word, they say, "You have to have a numeric value."
Your passwords must include at least one numeric or symbol. The idea is, "Now I have this great complexity; it's not a dictionary word." The problem is, human nature just uses the very simplest way of remembering that I added a number. So if I was using the password "password" before, now I'm using the password "password1," or "password!," or I'm using "passw0rd." These are simple ways that humans are able to meet a constraint check, but if you know that, then you actually haven't added any complexity, because it takes me a very short amount of time to test a dictionary word, and test if the Os are 0s, if there's a 1 on the end, or a symbol on the end.
The other one that people say is, "Oh, you need to use mixed case. Uppercase and lowercase." Well, what do people naturally do? They uppercase the first character. Now I'm just going to test the first character. If the constraint was, "You must use uppercase and lowercase, and you must use numeric or symbol values," and you figured out in your formula that you changed your character set size from, instead of just 26 characters, which, with an eight character password would give you an 8^26 number of possibilities that you'd have to brute force.
"I've added numbers and symbols and uppercase and lowercase." Well, if you add up uppercase and lowercase that's 52, add the numbers and symbols, I think it comes to like 76. In your mind, the person writing this filter rule, is, "I've increased my complexity from 8^26 to 8^76, there's no way they can crack that." What they've really done is, they've made it, like, 8^28, or 8^30, because there's only a few positions that these characters are going to be in.
Those are some of the rules that we're going to be building in, and I think that'll show that simple passwords constraints doesn't really have any value to complexity. The other thing we're working on is the idea of password reuse. People reusing passwords sort of ruins the value of the password, because the risk is, the more systems you use that password on, the more risk there is to that password, and the weakest link of those is going to be the weakness.
If I do online banking, and I have my online mail account, and I use the same password for those, and I also use it for some blog that's running somewhere on open source software that I have no idea where it comes from, and I'm using the same password, well, the weakest link is probably going to be that blog software. It's not going to be Gmail, it's not going to be Bank of America. So, someone breaks into that weakest link, and they recover passwords. Now everyone's using their e-mail address as their user ID everywhere, which, again, is another bad thing because now I can just try that user ID and password combination on every possible service, once I recover that password.
That's a problem that I think people understand, but that's a multi-organizational problem, and we're probably not going to solve that one. Within an organization, you have a similar kind of problem. If I have the same administrator password or help desk password on every single laptop, if a disgruntled employee is able to crack the password on their laptop that has some extra privileges, or just has any privileges on any other machines, now that disgruntled employee, after they're fired, still has access. I've seen places where your perimeter password on your radius system, when you dial in or when you connect in with a VPN, is the same as other passwords, like to the e-mail system. It isn't just internal, sometimes your internal and external facing passwords are the same.
I think it's important to understand if people are reusing passwords everywhere, and try to understand, organizationally, what impact does that have. That's another place where password auditing can really show a benefit. We're going to try to bring some of these new ideas into future version.
Interviewer: Kind of taking it personally that the product had been put on the shelf, I'm sure it's still used in a lot of places, did you get any kind of community feedback? "Boy, we'd like to see this come back, can you do anything about it?" Was that part of the equation at all?
Chris Wysopal: We knew a lot of people still used it. We knew that Symantec's, which used to be @stake, consulting services still used it. We know that there's value in it for security consultants out there, so we figured that the marketplace would react. We've gotten a lot of people that were LC 5 users coming to us now, some of them are saying, "I need a new license key because I need to move to a new machine," so we're starting to get the support burden of having a customer base. Also, "Looking for what's the new version going to have, and I'm interested in upgrading." We have had early indications that the demand is still out there.
Interviewer: How will you distribute it? Is it going to have its own business model, its own self-supporting . . .
Chris Wysopal: It's just going to be very simple. It's actually going to go back to the way it was in the L0pht days. Back in the L0pht days, we all had day jobs, and we didn't have a lot of time to run a separate software company. All of us today still have day jobs. It's really going to be something that's sold over the Web, supported online, and we're not looking just to be huge, we just want to make sure that there's a new version out there, and it's supported.