- From: Amir Herzberg <herzbea@macs.biu.ac.il>
- Date: Wed, 14 Jun 2006 08:53:58 +0300
- To: "James A. Donald" <jamesd@echeque.com>
- CC: Amir Herzberg <herzbea@macs.biu.ac.il>, public-usable-authentication@w3.org, Alex Dvorkin <kaledan@chaoslands.com>
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