Upgrade Routine for new releases about password-manager HOT 6 CLOSED

It's impossible to have this feature if all designs are implemented correctly. You can actually prove this.(1) And by the proof, you can know your passwords in all password managers that can be automatically upgraded are also accessible to the website admin.(2)

Proof of (1): Suppose we have such routine which maps old password R into new password H. And our raw password is P. We know R=AES(f(P),sk); H=AES(g(P),sk). Thus the map p: R->H would be:
p=AES(g(f^(-1)AES^(-1)(R)))=AES_g_f^(-1)_AES^(-1), p(R)=H
Our assumption here is that you can't solve AES and you don't know P (actually, you don't know g and f inverse as well without sk). It's obvious that g_f^(-1) won't give an identity map, and the elements in the function composition are not commutative. So you have no way to cancel AES and AES^(-1). Thus, you can't have such map p in explicit format. Actually, even if you can solve AES, the confusion algorithm is still unsolvable without conf_key.

Proof of (2): On the other hand, suppose we have a password manager that can upgrade algorithm without the involvement of users. let's say, the old algorithm gives map f, and the new one gives map g. Now let the new map be e (identity map), and upgrade. Since e(a)=a, you have all passwords in plaintext in your database.

from password-manager.

We could save the version number of the data for every user.
Then on login we could check this and offer the user to upgrade in his browser.

If you don't change the algorithm upgrading without user action should be possible(as it was when I implemented tags).

from password-manager.

It's like writing a decrypter JS and encrypter JS for each version, use the
old version decrypter gives you P and new encrypter gives you H.

Is it really different from keeping old versions (use new database for new
version) and asking users to export from old version and import to new
version? (I.e backup -> extract raw->import)

On Tuesday, 23 February 2016, Benjamin Häublein <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

We could save the version number of the data for every user.
Then on login we could check this and offer the user to upgrade in his
browser.

If you don't change the algorithm upgrading without user action should be
possible(as it was when I implemented tags).

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

from password-manager.

Yes, because this way the admin has to keep the old version until everybody did the backup. And there is no way of knowing whether everybody has done it.

from password-manager.

Ok. I'll think about implementing it in next algorithm update

On Tuesday, 23 February 2016, Benjamin Häublein [email protected]
wrote:

Yes, because this way the admin has to keep the old version until
everybody did the backup. And there is no way of knowing whether everybody
has done it.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

from password-manager.

I think the password manager is mature now. I don't have further plan to upgrade the algorithm (at least in near future...) Though I'll still implement the history track, IP block and fields customization. So I'll close this issue for now.

from password-manager.