So going back to the start of the thread:
-----Original Message-----
From: Jeff Robertson [mailto:jeff.robertson@digitalinsight.com]
It seems like it's been mentioned on here before, that a
number of "two factor" or "multi factor" authentication
schemes actually use a cookie as the second factor.
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?
This thread went in many directions and I'm not sure we
nailed your specific question down (which are usually good
questions so I'm curious :)).
Anyone here have specific experience with such solutions, or opinions
about how much security they add to a system?
Yes. In the CIA domain, there's been a lot of talk of this "something
you have" type situation. I don't buy it.
'cause the problem is, everybody on the planet could have a copy of my
signet ring, and nobody might realize it. If it were a cookie.
Of course there are associations one can make w/a cookie to limit
usage surface...mac, IP, etc., and their pluses and minuses which
we've discussed extensively on this list, but...
</caveats>
There's enough negatives to a persistent "auth" cookie, like automagically
being provided by the browser allowing things like session fixation
and CSRF, and all the historical browser cross-domain access flaws,
that I don't think the /caveats offset.
But that is me, and most of the rest of the weird web world has voted
otherwise. /$0.02
-ae
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
