Blizzard Entertainment, makers of the phenomenally-successful multiplayer game World of Warcraft, have introduced two-factor authentication for logging into the game.  For $6.50, they’ll sell you a dynamic password keychain token called the Blizzard Authenticator, which looks much like the RSA keyfobs many in the IT industry use to log into their corporate VPNs.

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (”something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

I don’t usually post about newly-discovered vulnerabilities, simply because there are so many of them — a dozen come out every day, especially in web applications.  However, this one has further-reaching consequences.  Security researcher HD Moore (of Metasploit fame) has discovered a vulnerability in the OpenSSL cryptographic random number generator used by Debian Linux, the widely-used distribution on which Ubuntu is based.  As I have discussed before, flaws in the RNG underlying a cryptosystem can compromise the entire system — both block ciphers and public-key systems rely on a source of entropy to create the large numbers they work with.  If the bits of entropy in this source is smaller than the key length, a “back door” is created — instead of cracking the key, you essentially “crack” the RNG, by trying all the possible seeds and seeing which one produces the key you need.

In this case, the result of this OpenSSL bug (an erroneous “bug fix” made in 2006) is to reduce the entropy in the seed to only 15 bits — a terribly small number (32,768) in cryptographic terms.  Moore was able to produce all the possible SSH keys that could be generated on this system in a matter of hours, save for those few people using 8192-bit RSA keys (and he’ll have those in a few days, too.  He’s placed them all on his website for download.

So what are the implications of this?  The most important one is SSH authorized keys.  SSH is the secure replacement for Telnet and FTP; security-conscious administrators and users use it instead of older protocols.  SSH has an option wherein instead of using a password to log in, you can save a set of keys in your user account, so that when you connect to another server the keys automatically authenticate you.  It’s quick, convenient, and generally more secure than passwords — and thus secures the most sensitive accounts (such as root) on almost all Linux-based servers.  With this exploit, it goes from being more secure than passwords to being much less secure — 32,768 guesses and you’re sure to get the right one.  This can be automated in a couple of hours if there is no lockout on the target machine (and the root account is normally not protected by a lockout since doing so means that an attacker can intentionally lock out the legitimate administrators.)  You could even use this as a local attack — log into your webhost account and run a script that will shortly give you root access to the server (from which you will have root access to most of the other servers at the hosting provider, too.)  Moore’s website includes a couple of scripts that can easily do this.

The nasty part about this is that keys are sticky.  Upgrading your Debian/Ubuntu servers to fix the bug is, of course, required.  However, also necessary is to replace every key generated on a Debian-based machine in the last two years (since 5/2/2006.)  It’s quite a task for administrators to even find all of those keys.  The first step is that if you use SSH to or from a Debian system, you need to immediately delete your authorized_keys and generate new sets (after applying the patch for this bug, of course.)  After that, it’s important to make sure all your users do the same.  Purging the SSH keys of all the users is not going to be a painless process and will undoubtedly involve some support cost, but keep in mind that not doing so is the equivalent of having all your users using 3-character lowercase alphabetic passwords.

The harder problem, though, is this: this bug isn’t really in SSH, it’s in the OpenSSL libraries.  These are commonly used by all sorts of apps to generate keys — OpenSSL is practically the Linux equivalent of CryptoAPI/DPAPI on Windows.  Everything uses them.  Essentially, every key generated on a Debian-based system for any purpose whatsoever in the last two years is potentially vulnerable.  You won’t be able to use HD Moore’s linked scripts to crack these, but they are all potentially cryptographically feasible now.  This is a major breach; if the NSA didn’t already know about this vulnerability (which I wouldn’t rule out), they’re no doubt engaging in a flurry of excited codebreaking right this minute.

Over at Schneier on Security, Bruce Schneier has a post today about securing data on disk. Encryption is often sold as a panacea for all security problems — which it’s not — but keeping people from reading your data if they steal your laptop is one thing encryption is really good at, and it’s an area where the real complexities of encryption (key management, key rotation, public key infrastructure) aren’t terribly important and can be safely neglected.

Schneier mentions Microsoft’s BitLocker in passing, and I wanted to add some detail. BitLocker is a whole-disk encryption system integrated into Windows Vista, and integrates with the Trusted Platform Module if available (the TPM is a smart chip on the mainboard that stores keys and performs secure cryptographic operations.) You tell BitLocker to encrypt your drive, and then choose one of several options for how to store the key. The simplest mode simply prevents someone from mounting the drive in another system or operating system, by storing the key in the TPM and retrieving it automatically on boot (this actually does make it significantly harder to get at the data on the disk without your password.) More complex modes store the key in the TPM and require either a PIN code from you or a certificate stored on a USB key to extract the key. Thus, on booting your PC you enter your PIN or insert the key, and the drive is unlocked.

The PGP product Schneier advocates encrypts the drive similarly to BitLocker, though rather than storing the key in the TPM it relies on a user-supplied passphrase to decrypt the key. While this is theoretically less secure (with the TPM, even the encrypted key is stored in tamper-resistant hardware and difficult to access), in practice it makes little difference — it’s still quite secure, and unlike BitLocker will let you encrypt other drives.

However, one feature BitLocker has and PGP lacks is key escrow. Now, this is normally thought of by privacy activists as an anti-feature, remembering the Clipper Chip fiasco of the late 90’s. However, the purpose of BitLocker’s key escrow is not to give a back-door key to the government, but rather to make the system palatable for enterprise deployment. Large corporations have traditionally been unwilling to embrace whole-disk encryption products like PGP even on laptops carrying sensitive data, for fear that the person with the key will forget the passphrase or simply leave the company and refuse to disclose it. By having the BitLocker keys escrowed with the domain controller such that appropriate corporate officers can retrieve it, it makes BitLocker “safe” for corporate use. If you’re not a domain member (i.e. it’s your home computer), then the keys aren’t escrowed with anyone else — there’s no government back-door.

Schneier rightly points out that an issue with any sort of whole-drive encryption is that they do not protect your data from government subpoena. If the government seizes your computer as evidence, they can (in the United States at least) subpoena the keys, and if you don’t turn them over you can be fined or jailed for contempt of court. This is not an issue for most (legal) data, but if you have something to hide from everyone, there are solutions other than the one Schneier posits (”just don’t keep data on your laptop that you don’t want subpoenaed.”) One option is the open-source disk encrypter TrueCrypt.

The problem with encrypted data on your disk is that it’s really obvious. It is not plausible to say “Oh, I don’t have any encrypted data” if served with a subpoena. For one, you probably have encryption software on your computer, and links to data that can’t be followed without decryption. But besides that, encrypted data is provably, mathematically distinguishable from almost everything else. Encrypted data consists of a binary blob with a uniform distribution across its entire data space — that is, any given byte is just as likely to be 00 as it is to be 01, 02, 03, or any other value. If you plotted it on a histogram, given enough data the graph would be approximately flat (subject to the variation and “clumpiness” always present in random data) and there would be no more repetition than expected by random chance. This is unlike every other type of data — executable programs, graphics, sound, word processor files, spreadsheets, etc. all have their own characteristic histograms and repeated patterns. Even compressed files have specific, recognizable headers and certain characteristic patterns (though they come closest to looking like encrypted data, since they have high entropy.) Thus, encrypted data stands out because it is “more random” than any other data on your hard drive. Since no one keeps large blobs of totally random noise on their hard drive, if one is found, it’s pretty certain to be encrypted data, and the courts know this (or at least can be convinced of it by expert witnesses.)

TrueCrypt has the feature of being able to place an encrypted volume inside an encrypted volume. Combined with the fact that it pads encrypted volumes with random noise, this leads to the ability to have plausible deniability of encrypted data. Essentially, it works as follows:

1. You create a TrueCrypt volume on your hard drive with a specified size, say 10 GB. TrueCrypt reserves that much space, and fills it with random noise.
2. You create a second TrueCrypt volume, with a different key, inside the first volume, with a smaller specified size, say 2 GB. TrueCrypt takes that space and fills it with different random noise.
3. When you want to access encrypted data, you mount both volumes. You put really secret stuff on the inner volume, and moderately secret stuff (e.g. pirated MP3s) on the outer volume.

Now, if someone gets your laptop, they can see that you have TrueCrypt installed, and that there is a 10GB encrypted volume (as there’s a 10GB blob of random noise on your hard drive.)  They force you to give them the key, and you do so.  This unlocks the outer volume, revealing its encrypted files.  However, there is no sign that the inner volume exists.  Unless you know it’s there, and know the key, there is no way to distinguish the random noise of its encrypted files from the random noise TrueCrypt filled the outer volume with anyway.  There could be a dozen encrypted volumes, or none — it’s impossible for anyone to know, and indeed, most people without a security mindset would never even think of such a thing.

Now, there are drawbacks to this technology.  If you mount the outer volume but not the inner one, neither TrueCrypt nor your operating system knows about the inner volume, either!  This means that writing files to the outer volume may overwrite and destroy the inner volume if you’ve not mounted it.  This isn’t a major problem, but it is inconvenient, especially if you have many volumes (as you need to type in the different passphrases and addresses of all of them every time you want to write to any of them.)  And no automation will help you, because having any would defeat the purpose — the existence of automation scripts would tip off a smart forensic investigator that your outer volume contains inner volumes.

It’s an interesting solution to the problem of plausible deniability — using steganography to hide encrypted data in encrypted data.  Admittedly, Schneier’s solution (just don’t have the data at all) is even safer, but sometimes that’s not good enough.

A pair of companies called Innovative Card Technologies and eMue Technologies have put out a press release for a one-time-password token embedded in a credit card.

Essentially, they embed a smart chip and an LCD display inside a bank card. When you need the password to your account (such as to log into online banking), you type your PIN into the card itself, and the display shows your password. This provides true two-factor authentication (something you have — the card — and something you know — the PIN) for online financial transactions, and is tamper-resistant.

Now, OTP tokens are not new. RSA has been producing the SecurID line for over a decade. However, they have not been widely adopted for online banking because of bulk and inconvenience. Nobody wants to have an extra device (they’re usually keychain fobs) that they have to find every time they log into their bank’s website. People want this even less because of the lack of standardization — you’d need one for every bank or credit card you have, and you’d need to be able to tell them apart. Embedding it in the card itself, though, solves this customer inconvenience. After all, you have the card on you anyway.

The trick now is to get banks to actually adopt this thing. This is very convenient for customers, and makes them substantially more secure. However, it requires the banks to actually buy the devices for all their customers — and eMue/InCard don’t say on their web site what they cost. An RSA SecurID keychain fob, however, costs $86, so I wouldn’t be terribly surprised if the cost to the banks of these cards is similar. And because of the costs, banks, like corporations, are inclined to go for what Alex at Worse Than Failure whimsically calls “Wish-It-Was-Two-Factor Authentication:” simply requiring you to provide something you know, and… something else you know.

The problem is that passwords are simply not very secure anymore. There was a time when even a modest password (say, an 8-letter combination not found in the dictionary) was pretty secure against most attackers. However, that time has passed; there are too many ways to crack a password. For example, if I want a user’s password so I can log into his online banking site, I could:

1. Lure him to my website, which installs spyware on his machine which records what he types.
2. Intercept his communication to the website and grab the password (mitigated by SSL login)
3. Steal his session cookies and hijack the session (mitigated by using SSL beginning-to-end on the website — common for banks/financial institutions, but rare for online email and other sites)
4. Wait for him to sign onto a public wireless hotspot, spoof the bank’s website, and steal the password with a man-in-the-middle attack (gets past the mitigations in #2 and #3)
5. Break into his email account, tell the website I “forgot” my password, and read the password-reset email it sends
6. Break into the banking website itself and get the encrypted password file. Admittedly, in this case I probably don’t even need to get his password anymore. But if I do, I can then use a rainbow table to break the encryption in seconds. A 12-character password with numbers and symbols still falls in seconds.
7. Break into any other website the user subscribes to; chances are he uses the same password on all of them
8. Send a phishing email tricking the user into supplying me with his password. He won’t fall for that? Send one asking him to sign up for some other service and create a username and password, then see #6

Password strength is irrelevant. Today, there’s really only two levels of password strength:

1. Guessable — blank, “password,” “secret,” your pet’s name, your wife’s birthday, a dictionary word
2. Not guessable — something meaningful only to you

There is not much variation in #2 — whether your password is “i like cheese” or “jR3&sJ7#iK9(wV2$” makes little difference (it makes no difference whatsoever to the 8 attacks listed above), but the former is far easier to remember. The problem with passwords isn’t that they’re too short, or not complex enough — it’s that a password is just data, and there are many ways to steal data.

So why do banks and corporate IT departments keep harping on longer, more complicated passwords? Why do banks require you to answer “secret questions?” (Technically called cognitive passwords — things like “what was your high school’s mascot?” — these are really just extra passwords, only required to be easily guessable.) Simple — it passes the cost, both in money and in effort, on to you. Asking the customer to answer extra questions, or the IT user to remember harder passwords, puts the onus of maintaining security on them. The IT department or bank doesn’t have to do anything at all to implement these “solutions” — it just asks you to do it. In the case of banks, there’s the added benefit of making people believe (falsely) that they are more secure by jumping through these hoops.

The problem is that these methods don’t actually do anything. Asking for “something you know and something else you know” is pointless; whatever method is used to steal the first password can also steal the cognitive password. Requiring strong passwords mitigates only against attack #6 above (stolen password database), and these days it doesn’t do even that (if your password is under 14 characters I can crack it in seconds with a rainbow table; even if the hashes are salted, preventing that sort of attack, distributed cracking with GPU offload will still get it in days.) What is needed is true two-factor authentication — not just for banks, but for anything online for which real authentication is required.

Unfortunately, this requires banks to shoulder the cost of providing either a token or a biometric reader to all their customers. The token is the simpler solution, though it has the disadvantage that, since there is no common token infrastructure out there, every bank or site has to do it. A biometric solution would scale better (one reader for every site,) but has a first-mover problem (which bank is going to give you the reader, thereby subsidizing all the other banks you use?) and may have robustness issues. This token-on-a-card technology is a good way to provide real security without inconveniencing the customer, and I hope to see it go somewhere.

Unfortunately, this is a case where the “security theater” (as Bruce Schneier calls it in Beyond Fear) interferes with real security. Banks have been telling us that their sites are secure, and their silly questions keep us safe. How do they now convince us that we’re not safe and we need to prefer the bank with the token-on-a-card? Without competitive pressure, there’s little incentive for banks to spend the money — but banks are loath to exert competitive pressure that harms public trust in the banking system.

A company called Elcomsoft has just put out a press release promoting the newest version of their Distributed Password Recovery tool, which is now capable of making use of the GPU (graphics processing unit) on modern 3D video cards for breaking password hashes.

Password hashes have been weak for quite a while now — as far back as 1997, it was practical, if you got a hold of the SAM hive from a Windows machine or the shadow file from a UNIX machine, to brute-force crack the passwords stored inside so long as they were relatively short and didn’t make use of obscure characters (hence all those “password complexity” guidelines urging you to use long, incomprehensible passwords.) However, at this point you could usually crack even a strong password in a few weeks using a desktop machine. This development cuts password cracking time by a factor of 20 or more.

Why is the GPU so much better than the CPU for cracking password hashes? Parallelism. Rendering a screen of graphics essentially consists of doing one task — figuring out what color a pixel on the screen should be — many, many times every second. As a result, graphics cards are optimized for doing many simple tasks simultaneously. CPUs, on the other hand, can do one task much faster than a GPU, but only do one thing at a time (multitasking is largely an illusion, as the CPU switches between tasks very quickly.) We’re just now seeing dual-core and quad-core CPUs, but a “dual-core GPU” would be nonsensical — they’ve got 10 or more processing pipelines already.

The Elcomsoft software further speeds up password cracking by allowing you to offload processing to many different machines, so each box tries a different section of the keyspace. If you have access to many machines, this can make it a very quick task.

Of course, sometimes you don’t need to go through this much work to crack a password. For any Windows password 14 characters or shorter, you can already crack it in seconds with a rainbow table attack. There are even online services that will do it for you for a small fee — you input the hash and PayPal a few bucks to them, they give you the password; if you’re willing to spend a few days on BitTorrent getting 64+ GB of data, you can get your own rainbow table for free.

So how do you make a safe password, when a table can crack it in seconds or new software in days, no matter how good it is? You don’t. There is basically no such thing as a strong password anymore — there is the total insecurity of having no password, or the moderate security of having a password. If someone manages to break into a server that your password works on, they will get your password if they want it. Not re-using passwords on multiple sites and servers is thus quite important if you care about what’s on it (we all use the same password on random registrations on the Internet, but you shouldn’t use that password for banking, too.) However, the only long-term solution to this is two-factor authentication; the password alone just isn’t enough anymore.