Post Mon Aug 12, 2013 4:57 pm

Evaluating threat scenarios

I just posted this to my blog:

Threat scenarios

When analyzing security features, we often look at them in black and white terms: either they can be broken or they can't. DES is crackable but as far as we know AES is not so we recommend AES. This is useful when we're making general recommendations because we don't know what threats everyone is going to be concerned about so it's safer to assume that we'll always need to protect against a skilled, well-funded attacker. In many cases, however, that assumption is not true.

At Passwords 13, Steve Thomas, a.k.a. sc00bzT, gave a presentation about building a cheap hardware security module (HSM) to store and protect passwords. During the talk, someone mentioned on IRC that what he developed wasn't a true HSM since the hardware was not tamper resistant. While that is a valid concern, others correctly pointed out that it may not matter depending on your threat scenario.

Since it has no physical protection, Thomas's HSM is vulnerable to hardware tampering. It should not be used in situations where that is a valid concern. If you're worried about foreign governments bribing your employees or about a rogue employee (e.g. at a bank) being able to sell those credentials, then you should consider laying out the cash to get a tamper-resistant HSM. But, if you're mostly worried about outsiders using SQL injection to dump your password hashes, this solution is perfect. It's cheap and it solves the problem.

In a similar vein, Google recently explained why they do not use a master password to protect stored passwords in Chrome:

"...the conclusion we always come to is that we don’t want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that’s really what they get."

The Wired article points out that, in an absolute sense, this is true but that whether this offers some protection in practice depends on your threat scenario. If you're worried about professional attackers, then Google is right. But, if you're only worried about a jealous lover or nosy family member, a master password does provide meaningful protection.

These anecdotes both illustrate the importance of threat scenarios. We don't defend against vulnerabilities, we defend against attacks made by threats. A SQL injection vulnerability is only significant because someone is out there ready to exploit it and because this action would be harmful to us.

Go here if you want to read the whole thing: