Re: Cookies as the second factor

You cannot trust the browser. At all.

Back in the day, there was a backdoor placed into the C language to  
trojan the login program. Whenever the compiler compiled itself, it  
copied the backdoor.

http://www.acm.org/classics/sep95/

How many compilers today bootstrapped themselves from a compiler  
related to this compiler? Could you trust a recompilation of the  
fixed C compiler?

In our case, Javascript is under the direct control of the attacker.  
They can make JS do ANYTHING they want and they have the source to do  
so.

Javascript is not a safe environment to compute security tokens. It  
can only be used in the negative, not the positive validation of a  
session, and as such is a defense in depth mechanism more than a  
trustworthy security control.

About the only good use I've seen for client-side JS use is "resource  
metering", or the application of hard computational algorithms on the  
client to rate limit brute force attacks to only those attackers with  
extremely large bot fleets.

Gunter's paper:
http://www.ngssoftware.com/papers/NISR- 
AntiBruteForceResourceMetering.pdf

thanks,
Andrew

On 19/07/2006, at 1:02 AM, Robin Wood wrote:

> Javascript could be used to generate the cookie which is then passed
> back to the server with each request.

smime.p7s
Description: S/MIME cryptographic signature