Re: [http-auth] [saag] re-call for IETF http-auth BoF

[Marsh Ray <[e-mail]>]

On 06/06/2011 07:20 PM, Stephen Farrell wrote:
>
> On 06/06/11 23:33, Marsh Ray wrote:
>>
>> Don't worry about it, they're not going to work even that well.
>
> Just trying to understand this. Why won't what work well?

Well you can probably make the math more efficient. You could certainly 
improve on the crypto handling ability of a language like Javascript 
which has neither secure memory overwrite nor constant time comparison 
operations.

But is there any plausible attack scenario where crypto in the web page 
adds meaningful security?

I don't think so. Either:

A. TLS is correctly securing the connection, in which case you could 
just as easily ship the plaintext to the server, or

B. TLS is not present or ineffective, in which case it's the attacker 
who controls what script is running in the page to such an extent that 
it's not even worth discussing distinctions in the degree of the 
compromise. I.e., pwned.

> (Compared to Tom, Dick and Harry each doing the same thing
> in their own favourite way?)
>
> Seriously - I think it'll be useful to know/document the
> limitations of this approach of developing a standard
> JS crypto API.

Anything done in client-side script happens only at the pleasure of an 
adversary who can break the security of the page (i.e. source or inject 
even the smallest fragment in the origin context of the site).

Therefore, client-side script is powerless to add real security.

This is not academic, obviously script injection is common in the real 
world. Some of the most common types of malware inject script into pages 
for the purpose of relaying login credentials (of course they could do 
almost anything since they are running binary code in the browser, it 
just happens that injecting script is the easiest way to do it).

- Marsh