Schneier on Security: Tagged passwords

Entries Tagged "passwords"

Page 23 of 27

Dogbert's Password Recovery Service for Morons

Posted on January 25, 2007 at 12:51 PM • View Comments

Choosing Secure Passwords

Ever since I wrote about the 34,000 MySpace passwords I analyzed, people have been asking how to choose secure passwords.

My piece aside, there’s been a lot written on this topic over the years—both serious and humorous—but most of it seems to be based on anecdotal suggestions rather than actual analytic evidence. What follows is some serious advice.

The attack I’m evaluating against is an offline password-guessing attack. This attack assumes that the attacker either has a copy of your encrypted document, or a server’s encrypted password file, and can try passwords as fast as he can. There are instances where this attack doesn’t make sense. ATM cards, for example, are secure even though they only have a four-digit PIN, because you can’t do offline password guessing. And the police are more likely to get a warrant for your Hotmail account than to bother trying to crack your e-mail password. Your encryption program’s key-escrow system is almost certainly more vulnerable than your password, as is any “secret question” you’ve set up in case you forget your password.

Offline password guessers have gotten both fast and smart. AccessData sells Password Recovery Toolkit, or PRTK. Depending on the software it’s attacking, PRTK can test up to hundreds of thousands of passwords per second, and it tests more common passwords sooner than obscure ones.

So the security of your password depends on two things: any details of the software that slow down password guessing, and in what order programs like PRTK guess different passwords.

Some software includes routines deliberately designed to slow down password guessing. Good encryption software doesn’t use your password as the encryption key; there’s a process that converts your password into the encryption key. And the software can make this process as slow as it wants.

The results are all over the map. Microsoft Office, for example, has a simple password-to-key conversion, so PRTK can test 350,000 Microsoft Word passwords per second on a 3-GHz Pentium 4, which is a reasonably current benchmark computer. WinZip used to be even worse—well over a million guesses per second for version 7.0—but with version 9.0, the cryptosystem’s ramp-up function has been substantially increased: PRTK can only test 900 passwords per second. PGP also makes things deliberately hard for programs like PRTK, also only allowing about 900 guesses per second.

When attacking programs with deliberately slow ramp-ups, it’s important to make every guess count. A simple six-character lowercase exhaustive character attack, “aaaaaa” through “zzzzzz,” has more than 308 million combinations. And it’s generally unproductive, because the program spends most of its time testing improbable passwords like “pqzrwj.”

According to Eric Thompson of AccessData, a typical password consists of a root plus an appendage. A root isn’t necessarily a dictionary word, but it’s something pronounceable. An appendage is either a suffix (90 percent of the time) or a prefix (10 percent of the time).

So the first attack PRTK performs is to test a dictionary of about 1,000 common passwords, things like “letmein,” “password,” “123456” and so on. Then it tests them each with about 100 common suffix appendages: “1,” “4u,” “69,” “abc,” “!” and so on. Believe it or not, it recovers about 24 percent of all passwords with these 100,000 combinations.

Then, PRTK goes through a series of increasingly complex root dictionaries and appendage dictionaries. The root dictionaries include:

Common word dictionary: 5,000 entries
Names dictionary: 10,000 entries
Comprehensive dictionary: 100,000 entries
Phonetic pattern dictionary: 1/10,000 of an exhaustive character search

The phonetic pattern dictionary is interesting. It’s not really a dictionary; it’s a Markov-chain routine that generates pronounceable English-language strings of a given length. For example, PRTK can generate and test a dictionary of very pronounceable six-character strings, or just-barely pronounceable seven-character strings. They’re working on generation routines for other languages.

PRTK also runs a four-character-string exhaustive search. It runs the dictionaries with lowercase (the most common), initial uppercase (the second most common), all uppercase and final uppercase. It runs the dictionaries with common substitutions: “$” for “s,” “@” for “a,” “1” for “l” and so on. Anything that’s “leet speak” is included here, like “3” for “e.”

The appendage dictionaries include things like:

All two-digit combinations
All dates from 1900 to 2006
All three-digit combinations
All single symbols
All single digit, plus single symbol
All two-symbol combinations

AccessData’s secret sauce is the order in which it runs the various root and appendage dictionary combinations. The company’s research indicates that the password sweet spot is a seven- to nine-character root plus a common appendage, and that it’s much more likely for someone to choose a hard-to-guess root than an uncommon appendage.

Normally, PRTK runs on a network of computers. Password guessing is a trivially distributable task, and it can easily run in the background. A large organization like the Secret Service can easily have hundreds of computers chugging away at someone’s password. A company called Tableau is building a specialized FPGA hardware add-on to speed up PRTK for slow programs like PGP and WinZip: roughly a 150- to 300-times performance increase.

How good is all of this? Eric Thompson estimates that with a couple of weeks’ to a month’s worth of time, his software breaks 55 percent to 65 percent of all passwords. (This depends, of course, very heavily on the application.) Those results are good, but not great.

But that assumes no biographical data. Whenever it can, AccessData collects whatever personal information it can on the subject before beginning. If it can see other passwords, it can make guesses about what types of passwords the subject uses. How big a root is used? What kind of root? Does he put appendages at the end or the beginning? Does he use substitutions? ZIP codes are common appendages, so those go into the file. So do addresses, names from the address book, other passwords and any other personal information. This data ups PRTK’s success rate a bit, but more importantly it reduces the time from weeks to days or even hours.

So if you want your password to be hard to guess, you should choose something not on any of the root or appendage lists. You should mix upper and lowercase in the middle of your root. You should add numbers and symbols in the middle of your root, not as common substitutions. Or drop your appendage in the middle of your root. Or use two roots with an appendage in the middle.

Even something lower down on PRTK’s dictionary list—the seven-character phonetic pattern dictionary—together with an uncommon appendage, is not going to be guessed. Neither is a password made up of the first letters of a sentence, especially if you throw numbers and symbols in the mix. And yes, these passwords are going to be hard to remember, which is why you should use a program like the free and open-source Password Safe to store them all in. (PRTK can test only 900 Password Safe 3.0 passwords per second.)

Even so, none of this might actually matter. AccessData sells another program, Forensic Toolkit, that, among other things, scans a hard drive for every printable character string. It looks in documents, in the Registry, in e-mail, in swap files, in deleted space on the hard drive … everywhere. And it creates a dictionary from that, and feeds it into PRTK.

And PRTK breaks more than 50 percent of passwords from this dictionary alone.

What’s happening is that the Windows operating system’s memory management leaves data all over the place in the normal course of operations. You’ll type your password into a program, and it gets stored in memory somewhere. Windows swaps the page out to disk, and it becomes the tail end of some file. It gets moved to some far out portion of your hard drive, and there it’ll sit forever. Linux and Mac OS aren’t any better in this regard.

I should point out that none of this has anything to do with the encryption algorithm or the key length. A weak 40-bit algorithm doesn’t make this attack easier, and a strong 256-bit algorithm doesn’t make it harder. These attacks simulate the process of the user entering the password into the computer, so the size of the resultant key is never an issue.

For years, I have said that the easiest way to break a cryptographic product is almost never by breaking the algorithm, that almost invariably there is a programming error that allows you to bypass the mathematics and break the product. A similar thing is going on here. The easiest way to guess a password isn’t to guess it at all, but to exploit the inherent insecurity in the underlying operating system.

This essay originally appeared on Wired.com.

Posted on January 11, 2007 at 8:04 AM • View Comments

Molecular Keypad Lock

Impressive:

…a group of scientists at the Weizmann Institute of Science in Rehovat, Israel have crafted a molecule-sized “keypad lock” that “only activates when exposed to the correct password, a sequence of chemicals and light.

Posted on January 5, 2007 at 7:01 AM • View Comments

How to Negate the Security of an Access Token

Everyone knows that writing your password on your monitor is bad security. Is it really so hard to realize that attaching your SecurID token to your computer is just as bad?

Posted on December 28, 2006 at 7:42 AM • View Comments

Real-World Passwords

How good are the passwords people are choosing to protect their computers and online accounts?

It’s a hard question to answer because data is scarce. But recently, a colleague sent me some spoils from a MySpace phishing attack: 34,000 actual user names and passwords.

The attack was pretty basic. The attackers created a fake MySpace login page, and collected login information when users thought they were accessing their own account on the site. The data was forwarded to various compromised web servers, where the attackers would harvest it later.

MySpace estimates that more than 100,000 people fell for the attack before it was shut down. The data I have is from two different collection points, and was cleaned of the small percentage of people who realized they were responding to a phishing attack. I analyzed the data, and this is what I learned.

Password Length: While 65 percent of passwords contain eight characters or less, 17 percent are made up of six characters or less. The average password is eight characters long.

Specifically, the length distribution looks like this:

1-4	0.82 percent
5	1.1 percent
6	15 percent
7	23 percent
8	25 percent
9	17 percent
10	13 percent
11	2.7 percent
12	0.93 percent
13-32	0.93 percent

Yes, there’s a 32-character password: “1ancheste23nite41ancheste23nite4.” Other long passwords are “fool2thinkfool2thinkol2think” and “dokitty17darling7g7darling7.”

Character Mix: While 81 percent of passwords are alphanumeric, 28 percent are just lowercase letters plus a single final digit—and two-thirds of those have the single digit 1. Only 3.8 percent of passwords are a single dictionary word, and another 12 percent are a single dictionary word plus a final digit—once again, two-thirds of the time that digit is 1.

numbers only	1.3 percent
letters only	9.6 percent
alphanumeric	81 percent
non-alphanumeric	8.3 percent

Only 0.34 percent of users have the user name portion of their e-mail address as their password.

Common Passwords: The top 20 passwords are (in order): password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1 and monkey. (Different analysis here.)

The most common password, “password1,” was used in 0.22 percent of all accounts. The frequency drops off pretty fast after that: “abc123” and “myspace1” were only used in 0.11 percent of all accounts, “soccer” in 0.04 percent and “monkey” in 0.02 percent.

For those who don’t know, Blink 182 is a band. Presumably lots of people use the band’s name because it has numbers in its name, and therefore it seems like a good password. The band Slipknot doesn’t have any numbers in its name, which explains the 1. The password “jordan23” refers to basketball player Michael Jordan and his number. And, of course, “myspace” and “myspace1” are easy-to-remember passwords for a MySpace account. I don’t know what the deal is with monkeys.

We used to quip that “password” is the most common password. Now it’s “password1.” Who said users haven’t learned anything about security?

But seriously, passwords are getting better. I’m impressed that less than 4 percent were dictionary words and that the great majority were at least alphanumeric. Writing in 1989, Daniel Klein was able to crack (.gz) 24 percent of his sample passwords with a small dictionary of just 63,000 words, and found that the average password was 6.4 characters long.

And in 1992 Gene Spafford cracked (.pdf) 20 percent of passwords with his dictionary, and found an average password length of 6.8 characters. (Both studied Unix passwords, with a maximum length at the time of 8 characters.) And they both reported a much greater percentage of all lowercase, and only upper- and lowercase, passwords than emerged in the MySpace data. The concept of choosing good passwords is getting through, at least a little.

On the other hand, the MySpace demographic is pretty young. Another password study (.pdf) in November looked at 200 corporate employee passwords: 20 percent letters only, 78 percent alphanumeric, 2.1 percent with non-alphanumeric characters, and a 7.8-character average length. Better than 15 years ago, but not as good as MySpace users. Kids really are the future.

None of this changes the reality that passwords have outlived their usefulness as a serious security device. Over the years, password crackers have been getting faster and faster. Current commercial products can test tens—even hundreds—of millions of passwords per second. At the same time, there’s a maximum complexity to the passwords average people are willing to memorize (.pdf). Those lines crossed years ago, and typical real-world passwords are now software-guessable. AccessData’s Password Recovery Toolkit—at 200,000 guesses per second—would have been able to crack 23 percent of the MySpace passwords in 30 minutes, 55 percent in 8 hours.

Of course, this analysis assumes that the attacker can get his hands on the encrypted password file and work on it offline, at his leisure; i.e., that the same password was used to encrypt an e-mail, file or hard drive. Passwords can still work if you can prevent offline password-guessing attacks, and watch for online guessing. They’re also fine in low-value security situations, or if you choose really complicated passwords and use something like Password Safe to store them. But otherwise, security by password alone is pretty risky.

This essay originally appeared on Wired.com.

Posted on December 14, 2006 at 7:39 AM • View Comments

Fighting Fraudulent Transactions

Last March I wrote that two-factor authentication isn’t going to reduce financial fraud or identity theft, that all it will do is force the criminals to change their tactics:

Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.

Here are two new active attacks we’re starting to see:

Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The solution is not to better authenticate the person, but to authenticate the transaction. (Think credit cards. No one checks your signature. They really don’t care if you’re you. They maintain security by authenticating the transactions.)

Of course, no one listens to me. U.S. regulators required banks to implement two-factor authentication by the end of this year. But customers are rebelling, and banks are scrambling to figure out something—anything—else. And, amazingly enough and purely by accident it seems, they’ve stumbled on security solutions that actually work:

Instead, to comply with new banking regulations and stem phishing losses, banks and the vendors who serve them are hurriedly putting together multipronged strategies that they say amount to “strong” authentication. The emerging approach generally consists of somehow recognizing a customer’s computer, asking additional challenge questions for risky behavior and putting in place back-end fraud detection.

[…]

Despite the FFIEC guidance about authentication, the emerging technologies that actually seem to hold the most promise for protecting the funds in consumer banking accounts aren’t authentication systems at all. They’re back-end systems that monitor for suspicious behavior.

Some of these tools are rule-based: If a customer from Nebraska signs on from, say, Romania, the bank can determine that the log-on always be considered suspect. Others are based on a risk score: That log-on from Romania would add points to a risk score, and when the score reaches a certain threshold, the bank takes action.

Flagged transactions can get bumped to second-factor authentication—usually, a call on the telephone, something the user has. This has long been done manually in the credit card world. Just think about the last phone call you got from your credit card company’s fraud department when you (or someone else) tried to make a large purchase with your credit card in Europe. Some banks, including Washington Mutual, are in the process of automating out-of-band phone calls for risky online transactions.

Exactly. That’s how you do it.

EDITED TO ADD (12/6): Another example.

Posted on November 27, 2006 at 6:07 AM • View Comments

Attacking Bank-Card PINs

Research paper by Omer Berkman and Odelia Moshe Ostrovsky: “The Unbearable Lightness of PIN Cracking“:

Abstract. We describe new attacks on the financial PIN processing API. The attacks apply to switches as well as to verification facilities. The attacks are extremely severe allowing an attacker to expose customer PINs by executing only one or two API calls per exposed PIN. One of the attacks uses only the translate function which is a required function in every switch. The other attacks abuse functions that are used to allow customers to select their PINs online. Some of the attacks can be applied on a switch even though the attacked functions require issuer’s keys which do not exist on a switch. This is particularly disturbing as it was widely believed that functions requiring issuer’s keys cannot do any harm if the respective keys are unavailable.

Basically, the paper describes an inherent flaw with the way ATM PINs are encrypted and transmitted on the international financial networks, making them vulnerable to attack from malicious insiders in a bank.

One of the most disturbing aspects of the attack is that you’re only as secure as the most untrusted bank on the network. Instead of just having to trust your own issuer bank that they have good security against insider fraud, you have to trust every other financial institution on the network as well. An insider at another bank can crack your ATM PIN if you withdraw money from any of the other bank’s ATMs.

The authors tell me that they’ve contacted the major credit card companies and banks with this information, and haven’t received much of a response. They believe it is now time to alert the public.

Posted on November 17, 2006 at 7:31 AM • View Comments

Keyboards and Covert Channels

Interesting research.

Abstract:

This paper introduces JitterBugs, a class of inline interception mechanisms that covertly transmit data by perturbing the timing of input events likely to affect externally observable network traffic. JitterBugs positioned at input devices deep within the trusted environment (e.g., hidden in cables or connectors) can leak sensitive data without compromising the host or its software. In particular, we show a practical Keyboard JitterBug that solves the data exfiltration problem for keystroke loggers by leaking captured passwords through small variations in the precise times at which keyboard events are delivered to the host. Whenever an interactive communication application (such as SSH, Telnet, instant messaging, etc) is running, a receiver monitoring the host’s network traffic can recover the leaked data, even when the session or link is encrypted. Our experiments suggest that simple Keyboard JitterBugs can be a practical technique for capturing and exfiltrating typed secrets under conventional OSes and interactive network applications, even when the receiver is many hops away on the Internet.

Posted on November 8, 2006 at 1:26 PM •

Seagate Encrypted Drive

Seagate has announced a product called DriveTrust, which provides hardware-based encryption on the drive itself. The technology is proprietary, but they use standard algorithms: AES and triple-DES, RSA, and SHA-1. Details on the key management are sketchy, but the system requires a pre-boot password and/or combination of biometrics to access the disk. And Seagate is working on some sort of enterprise-wide key management system to make it easier to deploy the technology company-wide.

The first target market is laptop computers. No computer manufacturer has announced support for DriveTrust yet.