AW: AW: AW: Secure Chrome

I strongly support this idea, having in mind that in Germany (and some other
countries) Transaction numbers (TANs) have to be typed into a HTML form,
which are somewhat different from passwords:
- they can not be chosen by the customer, they are generated by the bank.
- they can not automatically be modified.
- they are not bound to sessions, but to transactions.

XSS should be a topic for the next generation of browsers, together with a
secure object model for Javascript (which may be inside the scope of W3C).

Clearly outside our scope are malware-based attacks on internal browser
interfaces: http://www.infoworld.com/pdf/special_report/2006/18SRmalware.pdf


Joerg



-----Ursprüngliche Nachricht-----
Von: Amir Herzberg [mailto:amir.herzberg@gmail.com] 
Gesendet: Freitag, 14. Juli 2006 09:59
An: spam filter
Cc: Jörg Schwenk; public-usable-authentication@w3.org
Betreff: Re: AW: AW: Secure Chrome

spam filter wrote:
> On 6/15/06, Amir Herzberg <amir.herzberg@gmail.com> wrote:
>> Another thing which would have been really nice is a standard definition
>> of the sensitive fields (password, cc#, etc...) - like ECML (rest in
>> peace :-) ) but that is not as difficult to do by hand...
>
> This is an important area which is largely not addressed yet.  We need
> indicators for mutual authentication and session to prevent session
> takeover attacks and validate identity of the remote server.
>
> For example, a user can be made to authenticate to her bank, but
> through a XSS attack, that session can be taken over by an attacker in
> order to request sensative information.  If the bank proves its
> identity after authentication and throughout the session, such attacks
> could be preventable.
Absolutely, and more: such XSS attacks can be launched even against 
existing automated login mechanisms (pw managers). This can be prevented 
if sites provide the necessary details to allow the pw managers to send 
the login credentials over secure connection (not via form submit), or 
using an appropriate secure protocol. What I recommend is 
standardization of appropriate <META> info that will allow the 
client-side code (login manager) to use the appropriate secure mechanism.

I believe this goal is widely supported in this group and I think Thomas 
does think of it as part of the charter (is it not clear enough from the 
text?)

Best, Amir
>
>   - Jeff
>