WebApp Sec mailing list archives

RE: Cookies as the second factor


From: "Jeff Robertson" <jeff.robertson () digitalinsight com>
Date: Thu, 20 Jul 2006 14:08:22 -0400

-----Original Message-----
From: Arian J. Evans [mailto:arian.evans () anachronic com] 

How, exactly, were you meaning? A persistent token of some 
sort, or some salted/magic/machine-unique identifier 
generated on the fly, or something generated by client side script?


Ok, this is what I'm really wanting to know the value of:

A persistent cookie, presumably a pseudo-random value, is issued to user
when he first "registers" for his account. The server remembers the same
value, in the database, associated with this user.

On all subsequent logins by that user, in addition to standard password
verification, the presence of this cookie is checked for by the server,
and the value is compared against the one in the database.

If the cookie is not supplied or the value does not match the one in the
database, the login is not allowed to proceed, even though the user had
the correct password.

If every is correct, a completely separate, non-persistent session
cookie is issued to track the session after each login.

The persistent cookie and the session cookie have nothing to do with
each other.

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?

-------------------------------------------------------------------------
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
-------------------------------------------------------------------------


Current thread: