ところが、パスワードの「組み合わせの数」を考えるなら、10 文字で記号を 1 つ以上強制するのは、英数のみで 11 文字にするのと、そこまで変わらない。であれば、運用上は文字の種類を強制して覚えにくくなり、それを覚えられるような簡単なルールを設定されるよりは、桁数が多くて覚えやすいパスワードを指定するほうが、低コストで安全性を向上できるのだ。

ところが、今度は「パスワード長の上限」の存在が足かせになる。例えば 14 文字までしか入れられないといった制限は、この前提を大きく壊す。

しかし、本来パスワードには文字数の上限など必要ない。

パスワードを平文で DB に保存するような間違った設計の場合は、DB のカラムサイズを上限にしてしまいがちだが、パスワードのハッシュを取得して保存する場合は、入力がなんであれ保存する文字列の長さは一緒だ。短い上限を指定する理由はない。

とはいえ、無限にするわけにはいかないため、一応の上限として NIST(800-63B) の推奨する 64 文字などを指定すれば十分だろう。

SHOULD permit a maximum password length of at least 64 characters.

— https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver

なお 1Password の Master Password の最長は 125 文字とされている。

The maximum password length will be updated to 125 characters.

— https://www.1password.community/discussions/lounge/community-password-62-character-maximum-limit/150913

アンロックのたびに 125 文字打つのは現実的ではないため、ポリシーとして検討すべきは「最短で何文字以上か」だけになる。

1Password のデフォルトポリシーは 10 文字以上だが、NIST の定義では IDP などに指定するパスワードは 15 文字以上を推奨している。1Password は IDP とは少し異なり、Secret Key との 2FA ではあるが、重要度からも 15 文字以上の指定が妥当と言えるだろう。

SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.

— https://pages.nist.gov/800-63-4/sp800-63b.html#password-authenticators

ちなみに、15 文字を超えたあたりから、いわゆるパスワードそのものをこじ開けようとする攻撃のほとんどは現実的ではなくなる。簡単な単語になることも、よく使われるパスワードになることもなく、総当りも現実的ではない。

また、「長すぎて覚えられないからどこかにメモする」や「毎回打ってられないのでコピペ用にメモ帳に書いておく」「辞書変換に登録し "パスワード" と打ったら出てくる」といった、別のリスクが誘発される可能性もあるため、ポリシーを 15 文字以上にする理由もそこまでない。

Master Password は変えない

パスワードの定期変更が求められる時代があったが、今となっては NIST でも非推奨になっている。

SHALL NOT require subscribers to change passwords periodically

https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver

これは、定期的に変更するために「変更しても覚えられるような簡単なルール」でパスワードが作られてしまうことのリスクなどを踏まえたものだ。

変更が必要なのは、漏洩などが発覚したときであり、それ以外は変更を強制しても安全性に寄与するわけではない。

1Password でも Master Password を変えることは基本的にはない。

もし変える場合は、全てのアカウントで個別に変更する必要があるため、マルチアカウントが多いとかなり負荷になる。

漏洩などをやらかした場合でもなければ、変えることはないし、1Password もそれを求めてはこない。

だからこそ、ユーザは堅牢な 1 つの Master Password を慎重に管理する必要があるのだ。

Policy による強制

1Password の Business では、組織に参加するアカウントの Master Password にポリシーを設定し、強制することができる。

Business アカウントのパスワードポリシー

そして、このポリシーは組織ごとに設定するため、一人のユーザが様々な組織に入った場合に、「この組織は 15 文字以上」だが「この組織は 20 文字以上」といった差異が発生することがあり得る。

これまで使ってきた Master Password を共通で使えなくなってしまうと、新しく Master Password を作る必要が出る。複数の運用するのは 1Password の方針とは異なり、またブラウザ拡張やアプリなどでアカウントのスイッチが面倒になるため、新しい Master Password で既存のアカウントを更新するといった必要が出てしまうのだ。

特に何も考えず、ただ「長ければ良い」「記号が必須」などとポリシーを設定したチームのために、1Password 全体の運用が阻害される結果になるだけなので、いたずらに強いポリシーを設定するのは避けるべきなのだ。

以上を踏まえると以下のようなポリシーが落とし所になるだろう。

管理者: 15 文字以上、文字種設定無しのポリシーを設定
ユーザ: 20 文字程度の Master Password を 1 つ作って覚え、マルチアカウントで共通運用

「20 文字以上のパスワードなんて、覚えるのも打つのも無理だ」と思うかもしれないが、実際はやり方次第で無理ない範囲で実現できる。

その 1 つの重要な Master Password をどうやって作るか、それを考えてみよう。

長いパスワードの作り方

仮に 20 文字以上の Master Password を新しく作る場合、どのように作るのが良いだろうか?

20 文字あれば、小文字アルファベットだけでも 26^20 通りあり 2x10^30 で 二百穣 という単位になる。もはや、記号や数字といった文字種など気にする必要はなく、むしろ絶対に忘れないこと、入力がストレスにならないことを重視して作るべきとなる。

よくあるのは、フレーズを用いる方法だ。

例えば、単一の簡単な単語をそのままパスワードに使うのは危険だが、5 文字の単語を _ で区切って 4 つ繋げれば、それだけで 23 文字のパスワードを作ることができる。

apple_world_table_light (23)

この 4 つの単語をランダムに設定すると忘れてしまうようであれば、文章にしてしまうという方法もある。例えば、Let it be の歌詞の一部を引用して以下のようにすれば、33 文字のパスワードができる。

whisper-words-of-wisdom-let-it-be (33)

特に英語にこだわる必要もない。例えば、吾輩は猫であるをローマ字にすれば 36 文字のパスワードができる。

wagahaiha-nekodearu-namaeha-madanai (36)

エンジニアであれば、例えば以下のようなコード片を使うと、記号も入って 24 文字になる。手癖で打てるだろう。

console.debug(Date.now()) (24)

Master Password を作る際は、「20 文字以上の文字列を考える」ではなく、「自分が好きなフレーズをどこかから持ってくる」と考えるのが良いだろう。そうすれば、覚えやすく長い文字列を作ること自体はそこまで難しくない。それが「あからさまに推測しやすいも」のでなければ、長さだけで十分なエントロピーが確保できているため、強度の心配もない。

注意すべきは、ある程度の頻度で入力すること、またスマホでも入力することがあるので、そうした際にストレスになりすぎない点だ。

Master Password を忘れたら、1Password のサポートに連絡しても絶対に復旧してくれないため、絶対に忘れてはならない。長くて安全にしたからといって、覚えられなかったり打つのが面倒くさすぎて、メモ帳に書いておいたり、辞書変換に登録したりしてはいけない。

それさえできれば、変に文字種の指定などのルールを設ける必要などない。

Policy の途中変更

なお、1Password の Business アカウントでは、Policy は途中で変更することができる。例えば、これまで 13 文字以上だったポリシーを、15 文字以上に変更するといった操作だ。

この場合、すでに 13 文字の Master Password を指定していたユーザはどうなるかというと、特に何も起こらずそのまま使い続けることができる。Master Password を変更する場合に、更新されたポリシーを強制されるだけだ。

つまり、「Master Password が Policy を満たさないため再設定する」といったダイアログが出て、強制的に Master Password を変えさせるといったことはなく、アプリ上に通知が行くこともない。そして、何度も言うようにユーザは Master Password を基本的に変えない。

これは、Policy を強制したいのであれば、基本的にはアカウントを配る前に決めておく必要がある点に注意したい。ただし、管理者はユーザが既に持っている Master Password を変更させないとならないほど強いポリシーを後から強制するのは、前述のように避けるべきだ。

Master Password は誰にも見えない

何度も言うように、1Password の Master Password は「ユーザが記憶にのみ管理する」ものなので、1Password を運営する AgileBits であっても、その値を知ることは絶対にできない。

もちろん、Business アカウントであろうと、管理者がメンバーの Master Password を見たりすることは絶対にできない。

もしかしたら、自分が新しく別のチームに参加するにあたって、Master Password を共通して使うことに抵抗を覚える人もいるかもしれないが、Master Password はあくまでユーザ個人に紐づくもので、他に漏れる心配はないため、むしろきちんと共通して使うべきだ。

逆を言うと、Master Password を忘れても、誰もその値が何だったのかを教えてはくれないため、決して忘れてはならない。

Outro

覚えるべき最後の 1 つである Master Password を、十分に堅牢で記憶可能なものにする方法を解説した。

しかし、Master Password でアンロックできるアカウントについては、記憶に頼れない Secret Key を用いてログインする必要がある。

つまり、1Password のアカウント管理、特にリカバリを考えるときは、この Secret Key をいかに管理するかを十分に考える必要がある。次回は、Secret Key の運用について解説する。