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


Current thread: