RE: Cookies as the second factor

> Eoin Keary suggested -

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

RFC 2109 and 2965 both describe the goal to be solved by
the implementation more or less the same way:

"We describe here a way for an origin server to send state information
   to the user agent, and for the user agent to return the state
   information to the origin server.  The goal is to have a minimal
   impact on HTTP and user agents."
 - http://rfc.sunsite.dk/rfc/rfc2965.html

I don't spend a lot of time sliding down poles, so I'm not sure I
got your analogy, but simply the fact that potentially every other
entity in the world could share a copy of your "unique bit" and
automatically be receiving the same cookie predicated experience
due to this, certainly scores a point for:

!= security control



So, uh, yeah, good craig mate, thanks for the interesting visual
and here's to cookies!

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