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.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Cookies as the second factor

Subject: RE: Cookies as the second factor
Date: Tue, 18 Jul 2006 16:45:22 -0400
I'm skeptical of any activities like this occurring on the client, and
greatly scrutinize them when testing.

I once did a .mil that never sent the pw over the wire; it sent a hash
instead.  Sounds okay at first blush, but in reality the hash became the
new password; they were fooling themselves. 

Call me old-fashioned, call me conservative, risk-adverse,
non-progressive, whatever you want ... two factor to me (at this point
in time) doesn't include client side tricks. 



-----Original Message-----
From: Rogan Dawes [mailto:discard@dawes.za.net] 
Sent: Tuesday, July 18, 2006 11:54 AM
To: Robin Wood
Cc: Jeff Robertson; webappsec@securityfocus.com
Subject: Re: Cookies as the second factor

Robin Wood wrote:
Javascript could be used to generate the cookie which is then passed
back to the server with each request. This would save having to make
sure a value was posted or passed on the query string on each request.

Don't have time to think about how good this would be for
authentication but I think techincally it can be done.

Robin


That is actually quite an interesting approach to using a session 
identifier.

On the positive side, it means that you never send your password to the 
server. Depending on how clever your client-side javascript is, you may 
not even need to store the clear-text password on the server side (for 
verification purposes)

On the down side, it might expose you to session fixation attacks.

Regardless, I'd say that that cookie would then qualify as "something 
you know", rather than "something you have", since it is created based 
on your username and password.

Regards,

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


<Prev in Thread] Current Thread [Next in Thread>