Re: Cookies as the second factor

[Peter Watkins <peterw () tux org>]

On Thu, Jul 20, 2006 at 06:33:11PM -0700, Robert Hajime Lanning wrote:
> On 7/20/06, Jeff Robertson <jeff.robertson () digitalinsight com> wrote:
> > A) Does this qualify as "something you have", in any definition of the
> > term?
> > B) Regardless of (A), does it have much security value anyway?
>
> A) no.  way to easy to copy or erase.  (delete all cookies is a
> standard fixit measure)

I agree. The standard is "something you have", not "something you have
a copy of". A cookie is not a thing, it's a data transfer mechanism.
Re-use the same value over and over and the cookie is just carrying
"something you[r computer] know[s]". Hack a browser to provide something
like a SecurID token number or Digipass code as a cookie, and the cookie 
would be used to convey proof that a properly initialized SecurID or 
Digipass solution is "something you have".

(Speaking of current two factor auth mechanisms, does anyone really take
Entrust's grid seriously? It seems to me it's too vulnerable to copy+replay
attacks: photograph a user's grid, and what stops you from impersonating?
I think this could be easily fixed if Entrust were to issue a "transaction
number" after authenticating and provide space for the user to record a
series of such numbers on the grid card. Require the user to enter 
the last transaction number along with the values from the specified grid
cooridinates. Best case, physical design and user training mean the users
guard the transaction numbers more closely than the grid. Worst case, a
photocopy attacker 1) must use the grid before the grid's owner [i.e., while
the attacker still has a valid transaction number] and 2) the attacker's 
use [much like that of an attacker copying an S/Key sheet] will be detected 
the next time the legitimate user authenticates.)

> B) no.  way to easy to copy.

If you want to protect this cookie, you'll want to limit it to https. And
if you do that, you might as well use SSL/TLS client certificates, since 
they're well-established and more secure.

I'm not a huge fan of client-side certs (or SecurID/Digipass "software
tokens" running in normal desktop environments), as they seem fairly
vulnerable, thanks to spyware and the relatively weak physicial security
of most PCs. (Small [keyfob size] physical tokens -- SecurID, Digipass,
smart card -- are another matter entirely.) But I think a carefully planted
persistent cookie is definitely not "something you have", and would not be
as valuable as a client SSL/TLS keypair/cert.

Is it worth discussing the lack of Perfect Forward Secrecy in the RSA ciphers
of SSL/TLS that are used for virtually all https web traffic? It seems to me 
that an attacker with the server keypair, even if he couldn't launch a MITM for
some reason, could sniff/decrypt a persistent auth cookie and then replay it
against the real site for his own use later on. But such an attacker could not
use the decrypted https traffic to steal a client SSL/TLS key for reuse/replay,
nor could the attacker make future use of intercepted SecurID/Digipass data.

-Peter


-------------------------------------------------------------------------
Sponsored by: Watchfire

AppScan 6.5 is now available! New features for Web Services Testing, 
Advanced Automated Capabilities for Penetration Testers, PCI Compliance 
Reporting, Token Analysis, Authentication testing, Automated JavaScript 
execution and much more. 
Download a Free Trial of AppScan today!

https://www.watchfire.com/securearea/appscancamp.aspx?id=70150000000CYkc
-------------------------------------------------------------------------