25 December 2011

A recent news story noted that a U.S. government agency had
asked some researchers to
withhold
crucial details
about an experiment that showed that the avian flu strain A(H5N1) could
be changed to permit direct ferret-to-ferret spread.
While the problem the govenment is trying to solve is obvious, it's far from
clear that suppression is the right answer, especially in this
particular case.

There are a few obvious parallels to other situations. Most notably,
in 1940 American physicists decided to stop publishing
papers on nuclear fission. That fact itself — the absence
of published research —
convinced at least
one Soviet scientist, G.N. Flyorov,
that the Americans and British were working a bomb. Arguably,
this was the crucial factor in the Soviet decision to proceed
with their project; certainly Flyorov mentioned this aspect in his
letter to Stalin, and Stalin took that point very seriously.
(I apologize for pointing to a paper behind a paywall; it's the
most authoritative reference I know of. You can find other
discussion
here
and on
Flyorov's Wikipedia
page.)
In this case, while secrecy may have concealed important details, it
gave away "the high-order bit": the area looked promising enough
to investigate, despite the exigencies of wartime.

That moratorium was voluntary. In the 1960s and 1970s, though, the
NSA tried to suppress outside knowledge of
cryptography
and NSA's own work;
more to the point, they also tried to suppress
civilian academic research
on cryptography.
There were obvious constitutional problems with that, but the
Public Cryptography Study Group (formed by the
American Council on Education in response to the NSA's call for a dialog)
recommended a voluntary system:
researchers could submit their papers to NSA; it in turn could request
(but not demand) that certain things not be published.

As a vehicle for stopping or even slowing research, this notion was
a failure. Possibly, the NSA's intelligence-gathering efforts have been
hurt by widespread knowledge of cryptography; certainly, there's far
more information out there today than there was a generation ago.
In a very strong sense, though, they've won by losing: their real
mission of protecting the country has been helped by the flourishing
of cryptography for civilian use. To give just
one example, cell phone cloning in the 1990s was
largely
done for drug dealers
who wanted to be able to make and receive calls anonymously.
Today, though, cryptographic authentication is used, eliminating an entire
class of attacks.

It's also worth pointing to the tremendous achievements by academic
cryptographers who have shown how to
do more with modern cryptography than exchange keys and
encrypt and sign messages. What James Ellis, the GCHQ researcher
who invented
non-secret encryption —
what today is called public key cryptography — once said to
Whit Diffie is quite accurate: "You did more with it than we did".
But the NSA tried to suppress the entire field.

A third example is more recent still: the full disclosure of the details
of security holes in software. It is still debated if it's a
net benefit or not: do we benefit if the bad guys also learn of
the attacks?. On the other hand, it's indisputable that many holes
are closed (or closed promptly) solely because of disclosure or the
threat thereof. Too many companies respond to reports of attacks by
denying them, questioning the competence or integrity of the
discoverer, or even using legal means to try to suppress the report.
Far too often, it seems, bugs are fixed only because of this public
disclosure; without that, they'd remain unfixed, leaving systems
vulnerable to anyone who rediscovered the attack.

The conclusion, then, is that suppression has greater costs than
it might seem. But what about this case? As before, as is
shown in an interview with one of the scientists involved,
Ron A. M. Fouchier,
there
are costs and benefits.
For one thing, what these guys did can't
easily be replicated in a garage lab by amateurs:
"You need a very sophisticated specialist team and sophisticated facilities
to do this."
Terrorists have easier ways to launch bioattacks:

You could not do this work in your garage if you are a
terrorist organization. But what you can do is get viruses
out of the wild and grow them in your garage. There are
terrorist opportunities that are much, much
easier than to genetically modify H5N1 bird flu virus that are
probably much more effective.

And finally, there's the cost of suppression. It is clear from
the interview that public health officials need to know the details,
so they know which flu mutations to watch for. Too many people need
to know for secrecy to be effective:

We would be perfectly happy if this could be executed, but
we have some doubts. We have made a list of experts that
we could share this with, and that list adds up to well
over 100 organizations around the globe, and probably 1,000
experts. As soon as you share information with more than
10 people, the information will be on the street. And so
we have serious doubts whether this advice can be followed,
strictly speaking.

(I have personal experience with this. Some 20 years ago, I invented
DNS cache contamination attacks. After talking with various people,
I decided not to publish; choosing instead to share
the paper
with
trusted colleagues and with
CERT. These colleagues, in Washington
and elsewhere, undoubtedly shared it further still. Perhaps someone
shared it imprudently, perhaps it was stolen by hacking, or perhaps
the bad guys rediscovered the attack, but eventually the attack showed up in
the wild — at which point I published. I concluded that the real
effect of the delay was to hinder the development of countermeasures. In
other words, I was wrong to have held back the paper.)

The ultimate decision may rest on personal attitudes. To quote
Fouchier one more time, "The only people who want to hold back are the
biosecurity experts. They show zero tolerance to risk. The public health
specialists do not have this zero tolerance. I have not spoken to a single
public health specialist who was against publication."

27 December 2011

On a cryptography mailing list, someone asked how to check for
"similar" passwords if all that was stored was a hashed value.
The goal, of course, is to prevent people from doing things like
adding a period, incrementing a digit, etc.
Partly in jest, I suggested publishing the old password when a new
one is set. That would also discourage people from using the same
password for multiple services.

It's an evil idea, of course — but now I'm wondering if it
might actually make sense…

28 December 2011

Yesterday, I posted a deliberately
provocative idea, one I called "evil": disclosing old passwords when the
password is changed. The objections were predictable; I agree with many
of them. The idea, the problems with it, and what they say about passwords
are worth a deeper analysis.

The most trenchant objection was from people who reuse the same passwords
on multiple sites. Precisely: this, in my opinion, is the single biggest
security flaw with passwords as they're used today. Never mind the old
bugaboo about guessable passwords; while they're sometimes an issue (see
below), today's attackers are generally more likely to use
keystroke loggers
to collect passwords as they're typed,
launch phishing attacks,
or hack web sites and collect
them en masse, especially from poorly-designed servers that store
them in the clear. In the latter case, you're in serious trouble if
you've reused a login/password pair, because the attacker now knows
your credentials for many other sites.

The defense is simple: don't do that. Don't reuse passwords.

I can hear the objections to this, too: people have too many passwords
to remember, especially if they're all "strong".
I agree; I have over
100 passwords for web sites alone. The solution I suggest is obvious,
if you're willing to ignore religious doctrine: use a pseudo-random
generator to produce as many "strong" passwords as you need, and
store them somewhere safe and convenient. That's what I do; for me,
"safe and convenient" is encrypted cloud storage, so I can get at them
from the three computers and two iToys I regularly use. For other
people, it might be on an encrypted flash drive, or a piece of paper,
or even the proverbial yellow sticky attached to the monitor.

Yes, it's heretical; we've been told for decades that we shouldn't do
that. But security isn't a matter of being in a state of grace, nor is
insecurity equivalent to sin. Rather, it's a question of cost-effective
defenses against particular threats. For most passwords — repeat,
most — the threat is not someone who has wandered into
your home office, nor is someone likely to mug you for the flash drive
on your keychain in order to learn the password to your Twitter account.
Rather, they'll plant keystroke loggers and hack servers. They may
resort to guessing attacks, but almost always that's done for
targeted attacks, where they're trying to get you in particular. Against
ordinary, large-scale attacks, that isn't done as much; there's not
nearly as much benefit to the attacker. But if you follow my suggestion,
you can make your random passwords as strong as you wish, at no extra
cost; software can remember R@s1o+=/)ket` as easily as it can
123456.

Now — there are passwords one perhaps shouldn't treat that way.
Important passwords for access within your organization, where physical
access to your monitor becomes a concern, shouldn't get the yellow
sticky treatment. The same might hold true for bank account passwords,
even on home monitors. Again, though, you have to analyze the threat
model: who would benefit from your passwords, and how would they be able
to get them?

Let's turn back to my evil idea. The second most common objection (other
than "I can't remember that many strong passwords") had to do with patterns
of passwords.
Again, yes; that's precisely the weakness (and it is a weakness;
people
have written programs
to guess new passwords based on old ones) the idea was intended to
combat. A more interesting question is what threat model you're
trying to guard against if you bar similar successor passwords. The only
possible answer is that you think an adversary (a) has a given old
password, (b) hasn't yet extracted all necessary value from it;
and (c) values it (as opposed to an arbitrary one on that site)
enough to launch a similarity attack against against precisely
that user. I suspect that such cases are quite rare. Ordinary
passwords
are available in bulk; useful financial passwords are often employed
quickly to loot an account; login passwords are used quickly to plant
back doors.

So — why was my original idea "evil", if it it defended against
a serious problem or didn't really affect user security in any real
sense? The problem with it is that it encounters extremely strong
user resistance. I can't think of any countermeasures, but there's
rarely much benefit to annoying your users that much. If you have
that much of a problem with bad passwords, the proper solution is to
use a better authentication mechanism, not to make people very unhappy.

One more thing: when analyzing security behavior, look at the threat model
and ignore religion. The classic
Morris
and Thompson
paper on password security taught us an attack — password-guessing —
but it does not tell us when this is a threat. Treating it as holy writ
divorced from the surrounding reality does no one any good.