Thanks for following up on this. I had postulated Steps 2 & 3 in that order specifically because of the way that you had written the following sentence (with emphasis on “then”) in your earlier comment:
But in either, case (2→3 or 3→2), would the corrupted vault remain partially readable if the process is aborted in the middle of re-encrypting the vault items? If the order is 2→3, it seems that those items that were re-encrypted should still be useable; conversely, if the order is 3→2, it seems that those items that were not yet re-encrypted should still be useable (assuming that the old protected key is stored in the database until the new protected key replaces it).
You’re right, the order I had before was incorrect. Here’s the order upon reading the code again
update vault items and enc key (done in one request)
update emergency access keys
update organization admin password reset keys
post the new password hash to the server.
What I failed to appreciate before was the risk is that the auth hash is out-of-sync with the enc key. I don’t really think there’s a risk of vault item decryption corruption like I suggested previously, but that the password used to authenticate may be different than the password used to lock your encryption key if the previously mentioned issues arise.