The Password is Dead, Long Live the Password

This article from Information Week relates the ease by which a Graphics Processing Unit on a readily available graphics card renders 7 character passwords useless because they are too easily guessed.
So is the Password dead?  Beyond dead, a pile of bones picked clean?

To answer that, you have to think of the threat in the larger context. That's true of any security  arm-waving you encounter.

Consider other attack vectors sharing the same outcome (credential theft) or the same ultimate goal.

Then, think about the various security controls that address the steps in each of these attack vectors.

Only with this sort of methodical, thorough analysis can you get a good handle on the issue. For example...

Consider that the attack described in the article, a brute force password guessing attack, where the ciphertext / hash of a password is known ahead of time, is just one vector for password compromise.

Provided that the attacker cannot get the ciphertext in the first place (the /etc/shadow or the NTLM hash or what have you), then this kind of offline password guessing is rendered useless, itself.

So don't let the bad guys get your encrypted passwords.

Your controls (flaw remediation/patching, access control enforcement, and so forth) should reduce the likelihood of this significantly.

Another attack vector is that of brute force guessing against a logon interface. This attack can be hampered by logon failure delays that slow down the process and by account lockouts where several failed logons within a particular time window lock the account.

A way around these controls is to guess one password, each, for a long list of accounts. This delays the time between guesses for any one account.  Even if you exceed threshold of failed logons on that account, it happens outside the time window.

Logging combined with solid monitoring will, hopefully, notify someone of repeated logon failures. The logging part is easy. The monitoring can be harder, requiring some combination of technical and people/process solution (think SOC / incident response / CIRT).

Using a keylogger delivered through malware is probably a much easier way to steal credentials. A host of controls have to be in place to protect users from themselves, and protect operating systems from infection by such stuff.



So should we protect ourselves from GPU-based password cracking?  The problem is that the solutions are expensive or onerous.  Complex 12-character passwords are going to wreak havoc amongst the user community and use of smart cards or tokens or whatever, are going to cost a fortune.

Is this the best place to spend scant security dollars?  Or should you spend your infosec budget on a stone that takes out two birds?

That is, controls that not only protect password hashes but the other sensitive data on your servers and networks?  You need to do that anyway.

Replacing Passwords

NY Times has an article on authentication without using passwords.

The solution urged by the experts is to abandon passwords — and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties’ authenticity, using digital keys that we, as users, have no need to see.
...
As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code.
...
“Users on shared systems can easily set up a simple PIN code to protect any card from use by other users,” Mr. Cameron said.

While I don't deny that passwords have their problems, I want to think this solution over a little. Meanwhile, if anyone out there is awake, I'm curious to hear your thoughts.

Privacy or Security Engineering

Sears has a portal that lets you lookup past purchases. It also allows you to lookup purchases of others if you know their name and phone number. In violation of their own privacy policy. Oops.

The article makes a lot of noise about privacy issues, but to me this is primarily another example of poor (or no) security engineering.

By analyzing the data sensitivity, existing requirements (like that privacy policy), and the data flow for the portal, it should've been obvious that stronger authentication and authorization controls were needed.

Happy New Year

I mean it. Hope yours is safe and happy.

But the Storm Worm folks have dark agendas when they send out their evil holiday greeting emails at year's end.

I wonder if we will ever choose to solve the inherent insecurity of email? Or are we stuck because it's so hard to change from the current infrastructure. If the US can upgrade from NTSC to HDTV (mandated by law, and of course delayed numerous times), maybe governments need to force a change from SMTP to something less spoof-prone.