パスワード管理アプリの同期 DB が持ち出されたときの利用者側の手順（mSecure の例）
mSecure の開発元が、クラウド同期利用者の暗号化 DB のコピーを第三者に取られたと通知した。復号された証拠はないとしても、マスターパスワードと重要な保存パスワードの変更、2 要素の再登録、パスキーの置き換えまでやる。
いつ使うか
- mSecure Cloud で同期していた（現在・過去とも）
- 一般に、パスワード管理サービスの保管庫データが漏れたと通知されたとき
考え方
- 公式の設計では、端末で作った 46 文字の Account Key でデータを暗号化し、その鍵はアカウントパスワードで暗号化して端末だけに置く。これが本当なら総当たりは難しいが、通知は取られた項目や Account Key への影響に触れていない。設計の説明は流出範囲の根拠にはならない。
- アプリを消しても状況は変わらない（データはもう外にある）。
手順（優先順）
- マスターパスワードを長い新しいものに変える。
- 金融・メール・クラウド・業務 SaaS など重要な保存パスワードから順に変える。
- 保管庫に入れていた 2 要素の秘密（TOTP シード）は、各サービスで 2 要素を一度外して再登録する。シードが漏れていればコードを作られるため。
- 保管庫に入れていたパスキーは、各サービスで削除して作り直す。
- 保管庫のメモに置いていた API キー、リカバリーコード、秘密鍵も交換する。