24 November 2015

Two wellsprings nourished my muse. (The desire for that sort of poetic
imagery was not among them.) The first was a deep-rooted dissatisfaction
with common security advice. This common "wisdom"—I use the word
advisedly—often seemed to be outdated. Yes, it was the
distillation of years of conventional wisdom, but that was
precisely the problem: the world has changed; the advice hasn't.

Consider, for example,
passwords (and that specifically was the other source of
my discomfort). We all know what to do: pick strong passwords,
don't reuse them, don't write them down, etc. That all seems like
very sound advice—but it comes from a
1979 paper
by Morris and Thompson. The world was very different then. Many
people were still using hard-copy, electromechanical terminals,
people had very few logins, and neither defenders nor attackers had
much in the way of computational power.
None of that is true today.
Maybe the advice was
still sound, or maybe it wasn't, but very few people seemed to be
questioning it. In fact, the requirement was embedded in very
static
checklists
that sites were expected to follow.

Suppose that passwords are in fact terminally insecure. What
the alternative? The usual answer
is some form of two-factor authentication. Is that secure? Or is
two-factor authentication subject to its own problems?
If it's secure today, will it remain secure tomorrow? Computer
technology is an extremely dynamic field; not only does the
technology change, the applications and the threats change as well.
Let's put it like this—why should you expect the answers to
any of these questions to remain the same?

The only solution, I concluded, was to go back to first principles.
What were the fundamental assumptions behind security?
It turns out that for passwords, the main reason you need strong
passwords is if a site's password database is compromised. In other
words, a guessed password is the second failure; if the first
could be avoided, the second isn't an issue. But if a site can't
protect a password file, can it protect some other sort of
authentication database? That doesn't seem likely. What does that
mean for the security of other forms of authentication?

Threats also change. 21 years ago, when Bill Cheswick and I wrote
Firewalls and Internet Security,
no one was sending phishing emails to collect bank account passwords.
Of course, there were no online banks then (there was barely a Web),
but that's precisely the point. I eventually concluded that threats
could be mapped along two axes, how skilled the attacker was and how
much your site was being targeted:
Your defenses have to vary. Enterprise-scale
firewalls are useful against unskilled
joy hackers, they're only a speed bump to intelligence agencies, and
targeted attacks are often launched by insiders who are, by definition,
on the inside. Special-purpose internal firewalls, though, can be
very useful.

All of this and more went into
Thinking
Security.
It's an advanced book, not
a collection of checklists. I do give some advice based on today's
technologies and threats, but I show what assumptions that
advice is based on, and what sorts of changes would lead it to change.
I assume you already know what an encryption
algorithm is, so I concentrate on what encryption is and isn't
good for. The main focus is how to think about the problem.
I'm morally certain that right now, someone in Silicon Valley or
Tel Aviv or Hyderabad or Beijing or Accra or somewhere is
devising something that 10 years from now, we'll find indispensable,
but will have as profound an effect on security as today's smartphones
have had. (By the way—the iPhone is only about 8 years old,
but few people in high-tech can imagine life without it or an
Android phone. What's next?) How will we cope?

That's why I wrote this new book. Threats aren't static, so our
defenses and our thought processes can't be, either.