Re: AW: AW: Secure Chrome

Jörg Schwenk wrote:
> 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.
>   
Sure.
> Could the following be a standard way to change passwords:
>   
No, I didn't mean anything as complex as the suggestion below. All we 
need is a _convention_ for how we submit <old password>, <new password>. 
Namely, I'm not suggesting to completely replace password based 
authentication, simply since this is a major change to the sites. All we 
need is a simple convention to allow our extension to change the 
password. As it is now, we need to find the way by hand for each site - 
not very handy.

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...

Amir Herzberg
> - 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
>>
>>
>>
>>   
>>     
>
>

Received on Sunday, 9 July 2006 06:26:32 UTC