Boris Zbarsky wrote:
> 
> Not really.  And yes, I did read what you posted.

Here we go :)

 > I am only aware of one, the way how client side access (via JavaScript
 > for example) to a hash field is handled. While write access should
 > probably always set the passed value, read access is a bit more
 > difficult. Should the returned value be the computed hash or the
 > actual value? Although I tend to the former, this should still be
 > discussed. Related to this would be whether key event handlers should
 > be called or not (they could be used to reveal the entered text).



> 
> I'm just pointing out that if this is to solve the use cases you claim 
> it solves, there is nothing to discuss.  There is only one possible 
> course of action.

I'd generally agree, however one of the reasons why I posted this is to 
start a discussion about this topic, which should include all aspects. I 
could have missed something.

> 
> Of course if you're not actually trying to solve what you say you're 
> trying to solve, then this is up for discussion.

This would be rather senseless then, wouldnt it?

> 
> It still has the same issue: provides a false sense of security where 
> there is none.

Sorry, thats not true. Can you explain why? The password would not be 
revealed, replay attacks would be made "impossible".

Alexander
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to