"Less Password" 時代のアカウント防災訓練

Intro

震災の直後、復興のさなかに水害が起こり、再び全てが流される。能登の人々にとっては大変な 2024 年だったと思う。首都直下型や南海トラフはいつ起こってもおかしくないと言われ、戦火すら他人事ではなくなっている。

家に災害用の備蓄を用意するのと同様、定期的に「アカウント防災訓練」を個人的に実施するようになって数年経つ。

観点は「今、持っているものを全て失っても、リカバリできるだろうか?」だ。

現代のアカウントの管理は、"Password Less" を目指す過渡期で、中途半端に複雑だ。Password は無くなっているというより、集約された "Less Password" 状態であり、残る「最後の Password」を起点にどう全体を復元するかが、災害時リカバリの課題となる。これに失敗して全てが詰むと、仮に無事避難できたとしても、相当な喪失を味わうだろう。

現状の選択肢と設計方針を振り返りつつ、災害時にデジタルアカウントをどう守るかについて考えたい。

注意

このアカウント防災訓練は、特に答えを出しているつもりはなく、見直してみること自体はお勧めするが、ここに書くやり方を人に勧めたいわけではない。その時の状況や選択肢、個々の事情や主義/理想によって、結果は変わるだろう。

どちらかというと趣味の延長で、「こういうのを考えるのが楽しい」からやっている、が正直なところだ。

それを踏まえ、少しでも「あ、そういえば自分はどうなるだろう?」と思うきっかけになればと思い、今年初めて公開してみることにした。

前提

アカウント管理は、結局「どうリカバリするか」に行き着く。ただし、現代で言うリカバリは「Password を忘れた」だけではない。

Password を忘れたら、メールでリカバリできるかもしれない。では、そのメールのリカバリはどうなっているか?

Passkey で Password を無くせるかもしれない。でも Passkey を保存した Password Manager にはどう入るのか?

SMS で OTP を受信するにしても、スマホが手元にあればの話だ。

「アレが残っていれば大丈夫」「コレがあればなんとかなる」という前提は、それが手に入る場面でしか成立しない。

災害で家や職場をすべて失い、普段使っているデバイス(PC, スマホ, Authenticator etc)をすべて失った状態でも、普段使っているサービスに再び入れるだろうか?

アカウント防災訓練を、「ある日持っているものをすべて失ったら」という前提で行うと、いろいろなものが見えてくる。

もちろん、「そんな状況ならまあ、諦めるかな」と思う人もいるだろう。しかし、もし無事に避難できた場合に、そこから続く生活を前に、同じことを思えるかは考えてみてほしい。

リカバリチェーン

Password を忘れてリカバリするために、メールを受信する。

そのメールが Gmail だった場合、Google にログインが必要。

では、Google へのログインはどうやってリカバリすればいいか?

覚えられるような Password だとまずいので、複雑な Password を iPhone で作った? もしくは Passkey を保存した?

それを保存した iCloud にはどうやって入る?

Password は覚えていても、2FA が設定されていたら、、、それって SMS だっけ?

SMS は危ないから使うなって言われたので YubiKey にした?

デバイスが失われた時のためのバックアップコードは? 印刷したものは燃え、USB は流され、もちろん覚えてなんかいない。机に入れたらまずいだろと Dropbox に入れてあるけど、Dropbox には入れる?

こうした依存関係を把握すると、リカバリの連鎖は割と複雑になっていることが多い。

特に、二段階/要素認証の普及で、覚えておいた Password だけで入れるサービスは減った。一方、二段階/要素の選択肢が多く、フローもサービスによって異なる。そんなサービスを生活の中で、数え切れないほど使うようになった。全体を正確に把握するのは筆者にも難しい。ましてや一般ユーザは、あまり意識せず場当たり的に色々な場所に保存し、知らぬ間に複雑にしてしまっている場合もあるだろう。

最初にこのチェーンを把握し、どういう依存関係になっているかを把握すると良いだろう。

リカバリルート

このチェーンを辿ったときに、最後に行き着く場所を、便宜的に「リカバリルート」と呼ぶことにしよう。

多くの場合、Google、Apple、Microsoft、1Password などに行き着くことが多いと思う。意識せずに 2 つのサービスで相互に認証情報を保存し合っていると、どちらかに入っているうちは良いが、同時に入り直そうとすると、デッドロックする可能性もある。

その上で、SMS による TOTP、スマホの Passkey、会社で配られた YubiKey、銀行から送られてきた乱数表など、付随する何かを 2FA に用いている場合も多い。

登録時のバックアップコードまでちゃんと保存しているか、保存していたとしても、それが最新のものになっているかなど、普段使わないものは確認しておかないと、いざというとき使えないこともある。

基本的には、チェーンはシンプルな方が良い。筆者の場合は基本的に全て 1Password に保存し、1Password にさえログインできれば、ほぼ全て復旧できる状態だ。そのうえで、利便性のために中間(iCloud Keychain etc)にいくつかのコピーが挟まっているような状態にしている。

もちろん、1Password が SPoF で、コンプロマイズされれば終わる。LastPass のようなことが 1Password で起こらない保証は難しい。しかし、疑い出せばデバイスだって OS だって多角形の重箱にしか見えなくなる。素人が独自で考えたオリジナルの管理方法のように、自分だけが安全だと過信した泥船に乗ることを選ばない限りは、何かしらのリカバリルートを信用するしかないのが現実だろう。

セキュリティと可用性はトレードオフだが、多くの一般ユーザにとっては「攻撃されるリスク」よりも「ミスって詰む」リスクのほうがよっぽど高いと個人的には思っている。

また、Google や Apple は、災害など関係なく突然アカウントが Ban されるという事例が、探すと色々出てくるだろう。仮に Google 八部に会い、Google のサービスを使えなくなるのはしょうがないとしても、それによって他のすべてのサービスに入れなくなるのは避けたい。

米国大統領が変わった今、こうした米国ビッグテックは、それこそ隣の島で何かあったとき、どうなるんだろう?と思ったりもする。そういう心配をするなら OSS の Password Manager などを入れるのが筋だろうが、それにしても 1Password が便利すぎるし、一応カナダの会社だし、もう 10 年以上使ってだいぶ馴染んでる。元同僚が元社員で色々話を聞いたりもして個人的な安心感もあるので、ここにルートを預けている。

2FA

二要素認証は、構図としては以下のようになる。

「記憶」に頼る Password と独立させるために、YubiKey や Titan のような Authenticator の「所持」要素を入れるのは、2FA としては理想かもしれない。しかし、壊れたり流されたりすれば終わりだ。

実際、WebAuthn (not Passkey) が出てきた頃は、「2 つの Authenticator を買い、1 つは普段使い、1 つは貸金庫に保存」などという話もあった。しかし、物理 Authenticator を何個か使ってきたが、割とすぐ壊れ、何度か買い直したので、バックアップとしての心もとなさを感じている。

一方、Google Authenticator などの同期のないアプリは、端末移行などでミスって詰む人を何人も見てきた。そこで、同期ができる Authy などを使っていた時期もあるが、結局これも全て 1Password に集約した。Apple が Passkey を始めたモチベーションも、こうしたミスを防ぐためだった。だから Passkey の保管先も迷うこと無く 1Password を選んでいる。

最近では 2FA 適用時に、バックアップコードを提供することが多い。このバックアップコードも「災害」を前提に考えると、意外と保管が難しい。紙で印刷したり、USB に入れて貸金庫に入れても、何かのはずみでサービス側のコードを更新してしまうと、保管したものは無効になるという同期の問題もある。

結局、筆者は 2FA だろうがバックアップコードだろうが、全て 1Password のログインアイテムに、Password と一緒に保存している。二要素ではなく、俗に言う一要素二段階の状態だが、可用性を重視しているのでそれ自体は気にしていない。

代わりに、Passkey だろうと乱数表だろうと、全て 1Password に保存し、1Password の管理にだけ集中できるようにすることで、運用と認知の負荷をかなり下げることができている。

2FA は、簡単な Password が使い回されていた時代に、後付けで「それだけでは入れなくする」目的で追加された側面が大きいと考えている。すでに Password Manager で複雑な Password を登録し、さらに追加の要素を足しているのであれば、その時点でほとんどの攻撃に対策はできている。

それでも漏れる少しの隙を防ぎたいなら、それは個々の認知の負荷と運用練度の範囲でやればいいと思う。自分がやらかして詰むリスクよりも、コンプロマイズされるリスクの方が高いと思うのであればだ。

最後の Password

Password Less の終着点は、Password Manager の普及で、Passkey はその中継地点と捉えている。今の Passkey は Apple の最初のコンセプトとは変わり、FIDO ブランドの Discoverable Credentials という位置づけになっているが、元の「Device Bound Secret は端末を変えたときに困る」というコンセプトには前述の通り納得感がある。災害時も同じ状況だからだ。秘密鍵を同期で共有するなら何かしらの Password Manager が必要だ、そして、Password Manager をきちんと使っているなら、認証方法が Passkey であるかどうか自体はあまり大きな問題では無いと感じる。

結局、災害関係なく Password Manager は入れておくのが現代の前提と考えている。そして、災害宅の観点で最後に考えないといけないのは、その Password Manager のリカバリだ。これは、Google でも Apple でも 1Password でも、Password Less の流れとは裏腹に、最後には Password が出てくる。

Passkey を保存する Manager のリカバリに Passkey を使うと、鶏が卵を背負ってやってくるので、他に頼りにくい「ルート」であるサービスがリカバリ手段として提供できる手段は実は少ない。結局そこは Password を消せなのだ。

チェーンを辿った根っこにあるこの Password は、正規化すると「あらゆるサービスにこの Password で入っている」と同義だからだ。

これを失えば全部失い、これさえあれば他の Password は無くせる。そういう意味で "Password Less" の実態は、今のところこの「最後の Password」に集約する "Less Password" なのが現状だ。

しかし、さすがにリカバリルートになるようなアカウントに、Password だけで入れてしまっては不味すぎるので、二要素目がたされる。ここが問題だ。

リカバリルートリカバリ

Google, Apple, MS, Yahoo などは、Password に加えて SMS が必須になっているだろう。スマホさえもって逃げられればいいわけだが、スマホが持って逃げられているなら、セッションは生きているだろうから、リカバリがそもそも必要ない。

所持品を全て失い、避難先のホテルでラップトップを借りられたり、新しいデバイスを手に入れられたとき、Password は覚えているが、それだけで入れるかどうかは、確認しておいた方が良い。

また、こうした規模のベンダだと、リカバリのオプションも複数提供されており、SMS だけがルートではないかもしれない。それらオプションもたまに変わる。アカウントの設定で、何があれば詰まないのかを定期的に確認するのも、避難訓練の一つだ。

一方、筆者が選んだ 1Password の場合、リカバリには 3 つの情報が必要となる。

1. Email
2. Secret Key
3. Password

1 と 3 は、筆者は記憶に頼っている。特に 3 は、1Password を使っていれば高頻度で入力することになるため、普段使いしている筆者にとって問題はない。

1Password の場合、問題は 2 だ。これは登録時に付与される 34 桁のランダム文字列であり、最初くらいしか入力しないので、記憶に頼るのは難しい。

1Password は、この Secret Key の書かれた PDF を「Recovery Kit」として配布し、「印刷して金庫にしまっておくように」と啓蒙してくる。

Secret Key は、文字通り秘密情報なので、簡単には漏洩しないようにすべきだが、それだけではログインできないため、Password と一緒でなければ、直接書かれた Recovery Kit を保存するのは理にかなっている。Recovery Kit には Password を書く欄もあるが、ここは空けておいて、Password は記憶に頼るほうが良いだろうと思う。

これをどう守るか。これが最大の課題だ。

Recovery Kit

最初に思いつくのは、先程も出た「貸金庫」だろう。

ところで貸金庫は、震災があっても無事なものなのだろうか? 3.11 後の新聞などを探すと、一応残っていたという話もあるようだが、場所にもよる気がするので、信頼性はよくわからない。そもそも、ペライチの紙や USB メモリを保存しておくには、サブスクとしてちょっと高い。

ちなみに、最近だと行員の方の信頼性の話もあるが、換金できないモノなんかに興味はないだろうから、そこはどうでもいい。というか、そう考えると Secret Key だけが盗めてもなんにもならないので、機密性自体は重要ではなく、どちらかというとディザスタリカバリとして、「家ではない場所」に価値があるようにも思う。

関東大震災のような想定だと、もう少し遠隔地であれば良さそうだ。例えば北海道とか、海外とか。会社に支社でもあるなら、出張がてらそこにちょっと置かせてもらえれば、その方が良いかもしれない。というか、無事なオフィスがあるなら、機種変前に使ってた iPhone でも置いておきたいものだ。

まあ、被災した直後に、そんな遠くにモノを取りに行く余裕があるか怪しいし、有事でも起これば海外なんかしばらく行けない可能性もある。

そもそも、記録として紙は心もとない。USB に入れたり CD といったメディアも結構簡単に壊れる。一番安全なのは、金属か。ドッグタグなどに刻印しておけば、簡単には破損しなさそうだ。

金属などに刻んでおけば、瓦礫から発掘できないかとも思ったが、よく考えると瓦礫から掘り起こすならデカいほうが良い。デカくて、燃え残りそうで、瓦礫からもしかしたら取り出せそうな、大きな家具家電。そういうものに、消えないように刻んでおくのも、もしかしたらいいかもしれない。ちなみに、そのためにちゃんとした耐火金庫を買って設置できるなら、その方がいいだろう。

色々考えた結果物理は 3 つにした。

1. Secret Key を刻み込んだドックタグを作り、それを災害時に持ち出す防災カバンに取り付ける。
2. 家の中の一番デカくて頑丈そうな家電の一箇所に、刻み込んでおく(家族も知らない)。
3. 実家と会社に、セッションの生きたデバイスを置いておき、たまに確認する。

これは、「全て失ったら」の制約からは外れるが、すぐリカバリできる用のバックアップだ。物理バックアップは、ちゃんと考えると家の地下にシェルターでも欲しくなる。形あるものの儚さと扱いにくさを感じる。

ストーリー法での記憶

「全てを失った」を前提に物理保管を考えても無駄だ。

今回は暗黙的に「無事に逃げられた」という前提があるので、入れ墨やマイクロチップなども考えたが、体を傷つけてまで守るのが 1Password の Secret Key というのもなんか踏ん切りがつかなかった。やはり頼れるのは己の記憶だ。

34 桁のランダムな文字列を覚えるのは難しい、覚えてもすぐに忘れる。と思っていたが、実はこうした無意味なものを記憶する方法はいくつか知られている。

記憶力を競う「メモリースポーツ」という競技があるのだが、筆者はこれを「記憶力がいいギフテッドたちが己の素質を競っている」のだと、ずっと勘違いしていた。

実際には、無意味なものに意味を持たせ、記憶するためのメソッドがいくつかあり、その訓練の成果を競っており、選手の中には「地の記憶力はあまり関係ない」と言う人もいる。

その中の 1 つに、文字列を物語などに当てはめて覚える「ストーリー法」というのがあり、筆者はこれを用いて 1Password の Secret Key を「エピソードトーク」に仕立てて覚えることにした。筆者は丸暗記は苦手な人間なので、なるべく鮮烈に記憶に残すためには、嫌な思い出を混ぜるのが良さそうだったので、気持ちのいいエピソードではない。

結果、筆者にとっての防災訓練は、「エピソードトークの反復」で、実際に Secret Key を復元できるか、になっている。

これを 3 年くらい前に始めたが、今のところ完全な復元はできておらず、年一回の訓練では全然思い出せないことまではわかった。もう少し高い頻度で反復しないと、順番やハイフンの位置をミスる。

1Password の Secret Key は不変なので、今後も反復を繰り返して、100% 復元できるようにしたい。もしくは、もっとハッピーなエピソードの方がいいんだろうか?今からエピソードを変えるのも、復元時に混乱しそうで不安だ。

念を推しておくが、「こういうのを考えるのが楽しい」からやってるのだ。邪魔しないでほしい。

KYC によるリカバリ

そんな記憶の訓練をしないとだめなのか」と脅してしまっていると良くないので、実際はそんなに詰まなそうだという話もしておきたい。

世の中には「自分が自分であること」を証明できればなんとかなる場面が少なからずある。例えば被災時には、銀行や保険は、ある程度の本人確認でサービスを受けられるようになるといった仕組みになっている。

そして、同様に一定の認証を経て公共サービスはリカバリできる、つまりマイナンバーや運転免許は、どこかのタイミングで戻ってくることになるはずだ。(災害時に実際どういう運用になるのかは知らないのだが)

ここまで来ると、KYC を経て登録する系のサービスは、リカバリできる可能性が高い。一般的に、登録時に免許の撮影を求めるようなサービスだ。

そして、筆者が使っている Line Mobile は、KYC が通れば同じ番号の SIM を再発行してくれる。これは、実際に問い合わせて確認した。他の SIM でも同じかは知らない。

SIM が戻ってくるなら、端末さえ手に入れば SMS 認証が通るということになる。つまり、SMS は「自分が自分であること」を証明できれば、どこかのタイミングで戻ってくるリカバリ手段なのだ。

被災後、すぐに手に入るかはわからないが、いずれ戻って来るとわかっていれば、気持ちは非常に楽になる。それまで Password を忘れないようにしておけば、Google, Apple, MS, Yahoo などは、どこかでリカバリできることになる。

一般的に、SMS はその脆弱性がよく指摘され、使わない方が良いものとされてはいる。今後は使えなくなるかもしれない。

しかし、筆者はこの性質をバックアップとして使い、記憶ベースの Password と SMS で認証できるサービスに、1Password の Secret Key やいくつかのバックアップコードをバックアップしている。エピソードトークを正確に思い出せればすぐに入れるが、それに失敗しても詰んだりはしないということだ。

Passkey 普及などを、リテラシを差し置いて推し進めると、自爆で入れなくなる人も少なくないだろう。そういう人のカバーのためにも、KYC でリカバリできるサービスは増えていくような気が個人的にはしている。しかし、個別にはよくても 1Password 自体が KYC ではリカバリできないため、1 Hop 置いたバックアップをそのどこかに置いておくのは重要だ。もちろん、一緒に Password まで置いてはいけないのは、言うまでもない。

その他

KYC リカバリのルートには、マイナンバーカードがあるので、これがうまく使えないかとは思っている。今は、マイナンバーでログインできるサービスは非常に限られているが、そのどこかに任意の情報が保存できる領域があれば、市役所でマイナンバーカードを発行してもらえた時点でリカバリができる状態を作れるかもしれない。

もっと言えば、一般サービスがマイナンバーカードでログインできるようになれば楽になりそうに見えてくる。しかし、中にある秘密鍵自体は再発行で変わるため、単体でログインするような用途では券面情報(つまりマイナンバーそのもの)を求めることになり、ハードルが非常に高いはずだ。公開はされていないが、IDP 機能自体はあるはずなので、それがもう少し広く使われれば良いのだが、おそらく公共サービスだけなのだろう(その方が良いように思う)。

また、今回は「全てを失ったが、無事ではあった」という暗黙の前提だったので、いわゆる「本当の生体認証」なら通るかもしれない。Touch ID や Windows Hello のように、生体情報を Authenticator Unlock に使うものは多いが、本当に「生体情報を直接登録し認証に使うサービス」を筆者はまだ見たことがない。個人情報の問題もあって難しいのだろうが、こういう用途で使えるサービスがあったら 1 箇所くらい指紋やらを預けてもいいかという気もするので、あるならぜひ知りたい。

訓練成果

2024 年末時点で、筆者のリカバリプランは以下のようになっている。

全てを失った状態からは

1. Secret Key をなんとか取得し 1Password にログイン
   1. 持ち出した DogTag
   2. 瓦礫から掘り起こしたデカくて頑丈な家具
   3. エピソードトークから復元
2. そこから他の全てをリカバリ

もしくはこうだ。

1. 自分が自分であることを証明し KYC リカバリを進める
2. SIM の再発行を依頼し、電話番号をリカバリ
3. 端末を手に入れてバックアップサービスにログイン
4. そこから 1Password の Secret Key を取得
5. 1Password にログインし全てをリカバリ

独自メールの利用

メールでのリカバリに Gmail などの Web メールを使っては、サービスに依存することになる。

ここで、独自ドメインのメールを使っていれば、DNS の設定やクライアントを変えることで、サービスに依存しないメールの受信が可能になる。

ドメインを Cloudflare で取り、DNS もそれを使っているため、Cloudflare にさえ入れれば、メールリカバリの可用性も上がるだろう。

そこで、長年使ってきた Gmail をやめ、独自ドメインのメールを Google Workspace で使うことにした。これなら、Gmail を脱しながら Google のサービスを使い続けることができる。

しかし、10 年以上使っている依存をすぐに移行するのは難しく、2 年ほど経つが未だに並行運用になってしまっており、結果 2 個目のメールが増えただけになった状態だ。

この移行を完全にやり遂げるのは、半ばあきらめているが、一応メールリカバリも多重化したということで、無いよりは良かったと思いこむことにしている。

Outro

防災訓練としてはいるが、思考実験の側面も強い。

今回は自分のアカウントだけの話をしたが、家庭内 SE の役目を担っている場合、家族(特に高齢の両親など)のように、ネットリテラシが高くない人をカバーする必要もあるかもしれない。

筆者はこの訓練を定期的に行い、そのたびに色々と更新してきた。つまり、今後もその時々のインターネットや社会状況に応じて、更新し続ける必要があるだろう。

そういうものだと思って、年に一回くらいはなんとなく気にかけてみる機会になると良いと思う。なお、こういう運用を細かく公開するメリットは一般的にリスクしかないので、こういうエントリの公開は気をつけた方がいい(オススメはしない)。

ちなみに、筆者の最近のテーマはどちらかというと「自分が死んだときに残された家族にアカウントをどう移譲/処分してもらうか」というデジタル終活の方だ。プライバシーを守りつつ、必要なアカウントは家族が継続して使え、不要なものは処分し、誰かに継いでもらう必要があるものを移譲してもらう、などを考えると、こちらはもっと難しく、考え甲斐があって楽しい。

その話も、いずれ書いてみたい。