WebApp Sec mailing list archives
Re: Cookies as the second factor
From: "Ryan Barnett" <rcbarnett () gmail com>
Date: Tue, 18 Jul 2006 12:55:12 -0400
On 7/18/06, Rogan Dawes <discard () dawes za net> wrote:
Jeff Robertson wrote: > 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. > > Anyone here have specific experience with such solutions, or opinions > about how much security they add to a system? > Sounds completely bogus to me. The cookie is typically generated by the server, as a response to an authentication event (single or multi-factor). The cookie is then used to maintain that authentication from request to request. There is NO authentication component in such a cookie. It is created by the SERVER, and as such CANNOT qualify as an authentication factor at all.
I think we are mixing persistent/session cookie concepts here. I believe that the scenario that Jeff was trying to describe (and please correct me Jeff if I am wrong here) is if you use both a password and a persistent cookie to initially log into an appliaction and then the app can issue whatever sesisonid cookies it needs to track the session state and provide authorization. So, let's pretend you have - http://www.site.com/login.php. On this page, you have have a login form that requests user credentials - username/password. You then submit this data using POST to http://www.site.com/validate.php. Now, in this scenario, you already have a persistent cookie set with "Domain=www.site.com/validate.php" so the browser will send the cookie only to that URL. The script will first check the user credentials supplied and then the 2-factor check will also check the persistent cookie sent. If it successfully validates both, you are then redirected to some homepage interface and a new authenticated SesisonID is set. With this scenario, what I was trying to point out is the problem around how do you initially get a persistent cookie such as this to the end user for them to use? I guess you could send it to them email if you are using some SMTP encryption (GPG or something). Arian pointed out some valid issues to be considered (session fixation, etc...) however I don't see any more of a risk to a persistent cookie vs a session cookie if the persistent cookie is only 1-factor of a 2-factor auth system. For instance, I use SecurID. What happens if I lose my FOB and someone finds it? They can't use it successfully without knowing my 4 digit PIN number. This concept is similar to what we are talking about here. If someone is able to somehow grab my persistent cookie (via XSS or something) it would not provide direct access without also knowing my username/password combo. On a similar front - if you don't have the available funds to purchase something like RSA SecurID for each user (as they are around $70 a piece), you could try Entrust Identity Guard - http://www.entrust.com/strong-authentication/consumer-security/index.htm Here is a little demo web app - https://www.entrust.com/eval/demoguard/anybank/dual.htm This may not be perfect, but it is far less expensive than SecurID. -- Ryan C. Barnett Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache
Rogan ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------
------------------------------------------------------------------------- Sponsored by: WatchfireAppScan 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:
- Cookies as the second factor Jeff Robertson (Jul 18)
- Re: Cookies as the second factor Rogan Dawes (Jul 18)
- Re: Cookies as the second factor Robin Wood (Jul 18)
- Re: Cookies as the second factor Rogan Dawes (Jul 18)
- RE: Cookies as the second factor Matt Fisher (Jul 18)
- Re: Cookies as the second factor Andrew van der Stock (Jul 18)
- RE: Cookies as the second factor Randy Ollett (Jul 18)
- RE: Cookies as the second factor Andrew Chong (Jul 18)
- RE: Cookies as the second factor Ken Kousky (Jul 18)
- Re: Cookies as the second factor Robin Wood (Jul 18)
- Re: Cookies as the second factor Rogan Dawes (Jul 18)
- Re: Cookies as the second factor Ryan Barnett (Jul 18)
- RE: Cookies as the second factor Jeff Robertson (Jul 18)
- RE: Cookies as the second factor Matt Fisher (Jul 18)
- Re: Cookies as the second factor mikeiscool (Jul 18)
- Re: Cookies as the second factor Darren Bounds (Jul 18)
- RE: Cookies as the second factor Jeff Robertson (Jul 20)
- Re: Cookies as the second factor Robert Hajime Lanning (Jul 20)