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, 18 Jul 2006 12:55:12 -0400 |
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: Watchfire
https://www.watchfire.com/securearea/appscancamp.aspx?id=70150000000CYkc -------------------------------------------------------------------------
| Previous by Date: | RE: Cookies as the second factor, Jeff Robertson |
|---|---|
| Next by Date: | RE: Cookies as the second factor, Andrew Chong |
| Previous by Thread: | RE: Cookies as the second factor, Ken Kousky |
| Next by Thread: | RE: Cookies as the second factor, Jeff Robertson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |