Secure chrome `login`: join experiment or define `change pw` convention...

James suggested a simple way (below, with small comment) to allow users 
of a chrome/extension based login mechanisms to move to a new machine. 
This will blend with our  (prototype, not yet released) extension, which 
disables login entry via the web form and moves the login process to our 
(chrome) extension, which will be protected both by being on chrome and 
by user personalization (text/image).

James idea will allow us to support users moving to new machines, and 
protect against dictionary attack (weak passwords), provided that our 
extension actually changes the user's passwords. So far we didn't do 
this; one reason is that we are not aware of any convention as to 
password changing, and it seems quite difficult to do it automatically.

Are there any significant (e.g. banking) sites which would be willing to 
cooperate on such experiment? We won't need them to do much, just to 
coordinate the password update process, essentially.

Is there interest in defining a standard password-update process, to 
make such solutions viable?

Best, Amir Herzberg


James A. Donald wrote:
>
>     --
> James A. Donald:
> > > Oops, we are on a new computer?  Random number [from
> > > which passwords are constructed] is not there?  Then
> > > do an SRP login to the server of the company issuing
> > > the login program, and get a copy of the large
> > > random number.  This means that the company issuing
> > > the login program can launch a dictionary attack on
> > > your master password, as can anyone who has access
> > > to one of your logins and access to a computer on
> > > which you used the login program, but no one else
> > > can launch a dictionary attack.
>
> Amir Herzberg wrote:
> > Do you mean to authenticate to the `login helper
> > trusted party (LHTP)` using as a shared key the hash
> > of your master password, and they'll send the user's
> > `random number` ? That does seem a reasonable
> > solution.
>
> Yes, that is what I had in mind.  People could set up
> their own LHTP, and should, though I suspect that in 99%
> of cases they would not.
Agreed. One small comment: I don't think we really need SRP here. An TLS 
connection to the LHTP, over which we send the hashed pw, would be 
enough. This even allows a stateless LHTP (which does not even keep the 
hashed passwords, just returns a pseudorandom function applied to the 
received hash, using a secret key not shared with anybody).

We can probably do this by having, in the `master login` process to the 
login manager module, a field for identification of the LHTP e.g. by 
URL. And of course as another alternate solution, a user can simply 
enter the randomizer manually (e.g. have it printed, since it is not 
that secret).

so the real problem is the `update password` process - plus, would users 
agree for us to actually change their passwords....

Amir

Received on Wednesday, 14 June 2006 05:54:49 UTC