Re: Secure Your Network -- NSA-Style



DevilsPGD <spam_narf_spam@xxxxxxxxxxxx> wrote:
Ansgar -59cobalt-
Wiechers <usenet-2006@xxxxxxxxxxxxxxxx> wrote:
DevilsPGD <spam_narf_spam@xxxxxxxxxxxx> wrote:
In message <Xns98B0D2B2C50A7yoyass@xxxxxxxxxxxxx> Yohann wrote:
The guide, which checks in at just under 50 pages, is serious about
airtight network security, urging you, for example, to enforce a
password history of at least 24 different 12+ character passwords,
swapping out passwords at least once every 90 days. The free PDF
covers Windows and Unix security setups.

Good plan. You know what your average use does with a 12+ character
password? Guess... Oh that's right, sticky note on the monitor.

It will take your average use 4-6 weeks to learn the password
(assuming they only enter it a couple times a day), which means by
the time they learn it, they're half way to being forced to get a
new one.

You may want to actually read that document (page 7, to be precise),
because as of yet you obviously haven't.

Worse, if someone does compromise a password, they'll have an
average of 45 days (1.5 months!) to exploit it.

What would you suggest instead?

Something you are, something you have, something you know.

Meaning that you'll have to increase the complexity of your infra-
structure, which *may* open additional attack vectors.

Finger print or hand scanner (can they be defeated? Sure. But it's a
barrier to entry)

How do you handle a compromised token? Fingerprints are pretty easy to
spoof. Also with biometrics there's always a tradeoff between FRR and
FAR.

RSA SecurID, smartcard, even a magnetic swipe would do the trick.

A token could be copied without the holder noticing (except for SecurID
maybe, but that one comes at a price).

Passphrase (length, but no other complexity requirements -- It's goal
is only to be secure long enough for a stolen RSA SecurID to be
noticed, and must be easily memorized)

You probably won't notice that a token got compromised, because it was
not stolen but copied. Thus the password needs to be as good as the
other tokens, which leaves you with the original problem.

Don't get me wrong, n-factor authentication is a good thing as it raises
the bar, but it's not a silver bullet and it's not for everyone. You
need to be aware of the downsides (price, increased complexity) and
possible issues (FRR/FAR tradeoff, tokens being copied, ...). Also don't
forget that the document we're talking about is a "first steps" guide
and nothing more.

Besides, n-factor authentication does *not* address the problem of the
mean timeframe that an account can be exploited (which was my question).
It just helps to reduce the risk of a compromisation.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich
.