Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Cookies as the second factor |
|---|---|
| Date: | Tue, 25 Jul 2006 15:21:03 +0100 |
If we go way back, I dont believe the cookie was ever meant to be used for security but for simple state operations. Its like using crunchy peanut butter to slide down a pole easier.
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 -------------------------------------------------------------------------
-- Eoin Keary OWASP - Ireland http://www.owasp.org/local/ireland.html
------------------------------------------------------------------------- Sponsored by: Watchfire
https://www.watchfire.com/securearea/appscancamp.aspx?id=70150000000CYkc -------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Write-up by Amit Klein: "Forging HTTP request headers with Flash", Amit Klein (AKsecurity) |
|---|---|
| Next by Date: | RE: Cookies as the second factor, Arian J. Evans |
| Previous by Thread: | Re: Cookies as the second factor, Peter Watkins |
| Next by Thread: | RE: Cookies as the second factor, Arian J. Evans |
| Indexes: | [Date] [Thread] [Top] [All Lists] |