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 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> |
|---|---|---|
| ||
| Previous by Date: | RE: Cookies as the second factor, Matt Fisher |
|---|---|
| Next by Date: | Re: Cookies as the second factor, Darren Bounds |
| Previous by Thread: | Re: Cookies as the second factor, Rogan Dawes |
| Next by Thread: | Re: Cookies as the second factor, Andrew van der Stock |
| Indexes: | [Date] [Thread] [Top] [All Lists] |