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.

I was reading an article about web scanner coverage and false positives by Larry Suto that RSnake linked to on ha.ckers. Though this is only tangentially related to the actual paper, it reminded me of something interesting — the inevitability of false positives when detecting something rare.

When measuring the error of a detection process, there are three pertinent statistics — Type I error (false positive, detecting something that isn’t really there,) Type II error (false negative, missing something that is there,) and crossover error rate (the error rate at which the rates of Type I and Type II error are equal — essentially, the minimum error of the process.) We normally think of trying to minimize the crossover error rate — after all, we want detection processes that are as accurate as possible — but sometimes one sort of error is objectively worse than the other, so we will choose, say, to minimize false negatives even if this leads to more false positives being detected.

For instance, it is very annoying if the fingerprint scanner used to log onto your laptop fails to recognize you routinely, requiring you to use the reader repeatedly. Thus, too many false negatives annoy the user. Of course, if it let everyone in, that would be even worse, but we’re willing to run the risk that somebody with fingerprints sort of similar to yours might be able to get in if it makes the thing work better. On the other hand, if the fingerprint scanner is on the vault with the nuclear weapons in it, false positives are very bad, while a false negative is really not too terrible — you probably don’t need to access the nuclear weapons very often, so if you need to swipe your finger four times to get in, that’s okay. In this process, you’ll optimize to minimize Type I error, even if this raises your rate of Type II error and your crossover error rate.

However, what people often fail to recognize is that error rates become very oddly skewed when the thing to be detected is exceedingly rare. For instance, we currently have many processes in the country designed, ultimately, to detect terrorists — border guards, profiling, no-fly lists, etc. These all have error rates — sometimes, they would miss a real terrorist, and to the dismay of civil libertarians and air travelers everywhere, sometimes they “catch” innocent people.

A Type I error rate of 0.001% sounds pretty good. Imagine you have a terrorist detector with a Type II error rate of zero — it always detects real terrorists. And its Type I rate is only 0.001% — it generates false alarms only one time in 10,000. Sounds great, doesn’t it? We should make use of them immediately! If this thing points out a terrorist, you’ve got the right guy. The government can proudly advertise that their detector is 99.999% accurate.

But wait… there are 280 million people in the United States. How many are actual terrorists? I hope not very many, but let’s be paranoid and imagine there are 1,000 lying in wait (though I’d wager if there were, we might have seen at least one terrorist attack on U.S. soil sometime within the last 5 years.) This means that we’ll be scanning a real terrorist — and set off the alarm, since our terrorist detector has a false negative rate of zero — 0.000036% of the time. Our false positive rate is 0.001% is actually more than the rate of real terrorists in the population. In fact, while a negative from our terrorist detector is right every time, a positive from it is wrong 97% of the time. In other words, if the alarm goes off, you can be 3% sure that you’ve got the right guy!

Doesn’t sound so good put that way. When the alarm goes off, you can be almost certain (97% certain, at least) that you’ve got an innocent man. The problem of detecting a rare thing without false positives is actually quite difficult.

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.

Forbes.com recently had an article called “America’s Hackable Backbone” regarding the recent surge in SCADA hacking. SCADA, Supervisory Control And Data Acquisition, is a truly ancient protocol, in use for over 20 years, which was not remotely designed with security in mind. At the time, SCADA was used only on dedicated networks that lacked any connectivity to a network to which you could attach a general-purpose computer. Thus, the security it relied on was a combination of physical security — you needed to tap a line to get in — and obscurity — if you did get in, you’d need to both know SCADA and know the particular “magic names” of the devices you were trying to control.

I saw Ganesh Devarajan’s presentation on SCADA hacking at DefCon back in August. The protocol is relatively simple — simple enough to figure it out just running a sniffer for a while. And the things controlled by these systems can be utterly critical — nuclear power plants, subway systems, pipelines, manufacturing plants, etc. Some of what Devarajan demonstrated was attacking through simple fuzzing — just throwing masses of junk data into the systems and seeing what happens, since the input (presumed to come from trusted sources on a private network) is seldom validated. When fuzzing makes something fall over, that’s almost certainly a sign that a buffer overflow vulnerability lurks there — so even if you can’t stop the subway with a SCADA command, you can probably execute arbitrary code with one, and that can do anything (though it is, admittedly, significantly harder.)

However, as Forbes points out, you don’t need to really know how to control the system to extort ransom out of someone — the mere threat of controlling, say, a water treatment plant may get you what you want.

Fixing these systems normally requires replacing them — they’re so old that updating to a more modern system is seldom an option. Likewise, encryption is a decade out of reach for these systems. At the very least, they need to be completely isolated — a computer that can access a SCADA system should not be connected to a computer that can access the Internet. This creates a potential path for an attacker. Unfortunately, companies are moving in the opposite direction — rather than replacing and isolating SCADA, they’re wrapping it in XML, so that modern applications can use web services to manipulate SCADA systems. This makes sense from a usability perspective — just because your oil pipeline’s valves use 20-year-old control software doesn’t mean your engineers have to be working on 20-year old green-monochome-screened DOS boxes to operate them. However, from a security perspective it makes things even worse. The machines running these apps are on corporate LANs with Internet connectivity — and hacking SCADA wrapped in XML is every bit as easy as hacking raw SCADA. Putting something in XML doesn’t render it more secure — indeed, the accompanying metadata often makes it easier to decipher.

The real worry of these systems is that as the SCADA networks become more integrated with the Internet (SCADA over TCP/IP is already normal, and SCADA over XML is growing), we come closer to a world in which those action-movie scenarios where a hacker breaks into a computer and starts blowing up power plants, manipulating traffic lights, etc. are actually possible. Right now, “hacker terrorism” is mostly a financial threat — there’s little you can do to life safety from an Internet terminal most of the time. It would be preferable to keep it that way.

A man named John Stottlemire has found himself in some legal trouble for developing a piece of software that bypasses the coupon-protection DRM used by Coupons.com. Essentially, to keep users from printing dozens of copies of one of their free online coupons, Coupons.com forces you to install some client-side software which assigns a unique ID to your computer, which the server uses to verify that you’ve printed the coupon only once.

This is a rather pitiful way to enforce security, because it relies on a trusted client. Never trust the client — anything on the end-user’s PC is totally under the end-user’s control, and thus can’t be relied on to enforce security policy. What Coupons.com has done here is no different from websites putting their input validation in JavaScript running on the user’s browser — as if the user couldn’t disable JavaScript, or even save the page to their own hard drive and edit it.

Stottlemire’s hack simply deletes the unique ID, so every visit to Coupons.com is your “first” visit. He’s now being sued, on the grounds that this is bypassing digital rights management, and thus illegal under the Digital Millenium Copyright Act. The DMCA is very broad, and does prohibit any kind of encryption-cracking for the purpose of defeating copyright protection, even if what you do with your encryption-cracking is otherwise completely legal.

However, this is a pretty dubious legal claim. No encryption was bypassed — all his hack does is delete files off your own computer. Essentially, it’s no different from deleting your cookies to make ad networks forget who you are. As Stottlemire says, “I honestly think there are big problems when you are not allowed to delete files off of your computer.” In addition, he’s cracking a system whose purpose is to give away free coupons, so it’s going to be pretty hard to demonstrate monetary harm here.

The DMCA is often ridiculous in that it attaches legal protections to systems that are painfully weak. After all, Stottlemire wouldn’t be in any trouble for, say, printing out Coupons.com’s coupon, and then making 1000 photocopies of it. Nor if he just used their printer app, but told it to print to an image writer (thus creating a binary file rather than a piece of paper) and then printed that repeatedly. But when he writes software to perform these simple and obvious tasks, suddenly he’s a criminal?

In Coupons.com’s defense, the reason that their security is so bad is that their problem is impossible. You can’t send an image to someone’s machine, then trust that the machine will do only what you want (print one copy) and not what you don’t (print 1000 copies.) Someday, DRM vendors may even figure this out.

At Crypty 2007 in August, Eli Beeham, et. al. presented a paper called “How to Steal Cars,” describing how they have bypassed the KeyLoq remote keyless entry system — the system used in the majority of the remote keyless entry key fobs. These systems are supposed to be secure — they use a 32-bit block cipher to transmit a 64-bit key from the key fob, which, if it matches, unlocks the car. The key consists of an XOR of a car identifier (not secret, can be eavesdropped on) and a manufacturer key (secret.) It should take 2⁶⁴ iterations to crack the key — not really practical.

However, these researchers found a flaw in the cryptosystem. Due to a flawed protocol, they can mounting a chosen-plaintext attack on 2¹⁶ keys (requires about 65 minutes access to the car.) And once they have that, there’s a cryptanalytic attack on the manufacturer key (that’s a bit more cryptographically strenuous; they took 2 days to do it using 50 dual-core Opterons), which makes unlocking any car by that manufacturer very easy.

But do we care? Car thieves aren’t going to run up to your car with a radio antenna, spend 65 minutes gathering data, run back to their PC and run a cracking app, then come back and steal your car. It’s easier to just pick the lock, use a slim jim, or break a window. (Actually, these things are frighteningly easy, much more so than most people imagine; key-based locks are not very secure.) However, the risk isn’t from single attackers — it’s that this turns cars from having a physical lock to a software lock. Now that this attack is known, someone could make an effort to gather manufacturer keys from many car manufacturers and model years, and create a simple piece of software which (when paired with an appropriate-frequency radio antenna) opens any car by those manufacturers. The bad thing about software hacks to things that aren’t general-purpose computers is that they’re really hard to fix. If someone does come out with Car Unlocker for Windows Mobile PCs (or even cell phones), what do you do about it? You can’t just download a patch to your car. Manufacturers will change the keys in future cars, but there’s nothing to be done about current ones. One guy isn’t going to do this to steal one car… but someone might do it for organized crime to steal many cars.

It’s dangerous to embed cryptographic keys. Key management and rotation is actually a much, much harder problem than strong cryptography — it’s one thing to make the key hard to break, it’s quite another to be able to change it when it’s broken. (And if the target is high-value enough, it’s a when, not an if — just ask the RIAA and MPAA’s DRM developers.)