3 ms·

With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to genera

With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use. You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords. For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story. As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.

homakov 9y ago
That's what made me confused. There is no way to "change" password, only to create a new profile and migrate to it. And you can have many profiles at the same time (some with equal email). >For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good? > you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.

homakov 9y ago

That's what made me confused. There is no way to "change" password, only to create a new profile and migrate to it. And you can have many profiles at the same time (some with equal email). >For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good? > you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.