Re: SecureID vs Certificates

["Crist Clark" <crist.clark () globalstar com>]

George Capehart wrote:
> > Tony Miedaner wrote:
> >
> > Hi Folks,
> >
> > Kind of a high level questions on trade offs between SecureID or
> > Certificates.  It would seem pretty obvious that SecureID is a better
> > system BUT for many situations it would seem to me that certificates
> > would be a reasonable form of two factor authentication.  Can anyone
> > provide a good reason why not to use certificates over SecureID?
>
> The degree to which you can trust the cert is dependent upon several
> factors . . . 

[snip]

> you've got to trust the Web...

"Trust the Web?" What does that mean and why must one trust it?

[snip]

> > Is it even reasonable to classify certificates as two factor?
>
> No.  Two factor is usually defined as something you have and something
> you know.  *Even if* the user protects the cert with a passcode,
> that's doing is the equivalent of keeping your ATM card in your wallet
> and your wallet in your pocket.  ATMs require two-factor
> authentication.  That's why you have to present your card and then key
> in the PIN.  That's also why SecureID users have to append the PIN they
> chose to the numbers generated by the SecureID device.  Two factor
> authentication with a cert would require the presentation of the cert
> along with a PIN or something else.  A cert by itself would be no better
> than an ATM card by itself . . .

Not clear here. At the top it sounds like you are going to say a
cert is not two factor and then go on to say that it is?

One thing to note here any way is that a password protected cert 
is obviously as strong, if not a little bit stronger, than a SecurID 
soft-token (I forget if there is a special name for those).

> > It is understood that if someone can take control your computer they
> > may be able to use the cert.
>
> Yep.  Especially if it's not passcode protected.  But it's not necessary
> to take control of the computer to use the cert.  All that's required is
> to be able to snarf it anytime between the time it leaves the computer
> and the time it gets to its destination.

This is flat out wrong. Any non-broken implementation of certs is not
trivially exploitable by snooping or man-in-the-middle attacks.

Both methods have huge margins for abuse by the end luser. An 
unprotected cert on notebook PC is bad. A SecurID card with the PIN
written on it or stuck to it on a Post-It(tm) node is bad. Two things
to consider, IMHO, (1) which, when properly deployed, is stronger, and
(2) which is more practical to properly deploy. Unlike many others here,
I think a _properly deployed_ certs would be the more secure solution. 
However, properly deploying certs is harder from both the administrators'
perspective and from a user compliance standpoint (IMHO again). Difficult
enough that SecurID (hard-token only, BTW) may be the better choice. But 
YMMV. If you are one of the three IS sec people on the planet with 
technically proficient, security concious users (lucky bastard), you might 
be able to pull off certs beautifully.

Of course, if we expand "certs" to mean things like smart cards then 
we have a much more secure solution which is more (but not completely)
idiot proof, but is a lot more expensive to deploy.
-- 
Crist J. Clark                                Network Security Engineer
crist.clark () globalstar com                    Globalstar, L.P.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards