> Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background.
I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage.
According to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault.
To handle its use as a login password they probably have a table somewhere that contains:
email, salt1, hash1(master_password,salt1)
I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty.
To handle updating login hashing they could change that table to contain for accounts that have logged in or been created after the difficulty change:
email, salt2, hash2(master_password, salt2), NULL
and for accounts created before the change that have not yet logged in:
email, salt2, hash2(hash1(master_password, salt1), salt2), salt1
For the vault storage, they'd have to change it so that instead of just singly encrypted vaults, Encrypt(vault, derived_pass), it can also store doubly encrypted vaults, Encrypt(Encrypt(vault, derived_pass), derived_pass2).
When they do the change, they would change existing vaults to double encrypted, with derived_pass2 = hash1(master_password, salt1).
When someone logs in for the first time after the change, they supply master_password. The server would see from the login hash table that salt1 is not NULL meaning they are an un-upgraded account. It could then compute
temp = hash1(master_password, salt1)
pwhash = hash2(temp, salt2)
and see if that matches the hash in the login hash table. If it does the login is successful, and it can (a) generate a new salt and update the login hash table to contain:
email, new_salt, hash2(master_password, new_salt), NULL
and (b) use hash1(master_password, salt1) to remove the double encryption from the vault, use master_password to decrypt the vault, and then re-encrypt with a new derived password with the new upgraded work factor.
NOTE: the above is based on documentation of theirs that says you use the master password for logging in to your account. However other documentation of theirs says that the master password is never sent to their servers.