AW: AW: Secure Chrome

Amir, thanks for the information. We have a group working on XML security
here, so it would be nice to get some details when you have finished the
implementation.

Could the following be a standard way to change passwords:
- m master password
- s secret random number, stored in browser and at the `login helper trusted
party (LHTP)`
- d DNS domain name of the web site visited, which is also stored in the SSL
certificate
- x = HMAC(m; s, d)   [HMAC is implemented in TLS]
- new_passwd: the last (first) n characters of the base64 encoding of x,
excluding padding

Joerg Schwenk

-----Ursprüngliche Nachricht-----
Von: Amir Herzberg [mailto:amir.herzberg@gmail.com] 
Gesendet: Donnerstag, 15. Juni 2006 00:09
An: Jörg Schwenk
Cc: public-usable-authentication@w3.org
Betreff: Re: AW: Secure Chrome

Jörg Schwenk wrote:
> Sounds like a very interesting idea, and I can imagine how it works for
> standard username/password. Do you have any ideas how to handle
non-standard
> logins, e.g. username/email/creditcard/password, or transaction numbers
from
> a TAN list (system used by all german banks)?
>   
Joerg, thanks. Yes, actually, our prototype already handles other fields 
(not only passwords) and indeed a very natural other application is to 
protect credit card numbers , and of course other input fields. We use 
an XML schema for identifying the relevant fields, etc., so it is quite 
easy to extend.

One problem, though, is that we don't have a standard mechanism for 
changing user's password.

Amir Herzberg
> Joerg Schwenk
>
> -----Ursprüngliche Nachricht-----
> Von: public-usable-authentication-request@w3.org
> [mailto:public-usable-authentication-request@w3.org] Im Auftrag von Amir
> Herzberg
> Gesendet: Dienstag, 13. Juni 2006 17:47
> An: James A. Donald
> Cc: public-usable-authentication@w3.org
> Betreff: Re: Secure Chrome
>
>
> James A. Donald wrote:
>   
>> User does not look at routine chrome.  Does not look at
>> irrelevant information.
>>     
> agree
>   
>> We have to make the login page special in an obvious and
>> dramatic way - and not make all the other pages special,
>> because then it just turns into noise and the user tunes
>> it out - so login and account creation has to be part of
>> the browser, not a web page.
>>     
> I agree. Our in-development code modifies login pages so that login is 
> always done via our control in the Chrome - user never enters password 
> in a web form (we can also auto-fill the password so users don't need to 
> type it at all). Feedback?
>
> Amir Herzberg
>
>
>
>