OSのユーザーパスワードを長くする必要はない

OSのユーザーパスワードはそこまで長くなくてもいい。 OSのユーザーパスワードと言ってもいろいろあると思うが、今回想定しているのはユーザーセッションのログインや、sudo, doasなどでの特権昇格に使うパスワードである。

まず、このパスワードが何から保護しているのか考える。 退けられるのは、電源を付けたまま席を外した隙にキーマップをEmacs風に変更しようとする友人、ユーザー権限でのRCEが行われた時に正規手段(sudo, doasなど)で特権奪取を試みるクラッカーぐらいだろう。

逆に何から保護していないか。 トイレに行った隙にあなたのPCにOpenBSDを導入しようとする友人や、特権奪取に洗練されたエクスプロイトを使用してくるクラッカーだ。特に前者は厄介で、PCはUEFIの支援を受けたロックが一般に強固でないから、訓練された友人なら数時間あればあなたの計算機でOpenBSDを動かすことができるだろう。最もこのことでデータの耐久性を心配することはない。単に消去したいなら殴る方がシンプルでより良い解決策だ。

「対して長くない」とはどのくらいか。 今まで挙げた「このパスワードが保護するもの」は全てレートリミットが有効に機能する前提である。パスワードには大きく2つ、秒間数億以上の試行を宇宙が終るまで耐える指向のものと、せいぜい数十とか、数万とか、それぐらいの試行を耐えられればいいものがある。 OSのユーザーパスワードは後者である。

ではどれくらいの長さがいいか

OSのユーザーパスワードの場合は、例えばLinuxのPAMは最近ならデフォルトで3回失敗すると10分ロックされる。厳しすぎると思うので緩和して使っているが、デフォルトのままなら1日に432回、1年で15万回の試行が行える。1ヶ月もパソコンを放置してスクリーンロックを試され続けるならその状況を改善するべきだと考えるので、「15万回の試行でパスワードが当てられる確率を許容可能なものにする」ことを要件にしてみる。

小文字アルファベットからランダムに6文字選ぶと、組み合わせは3億になる。1年試して当たる確率は0.5%。ソシャゲ中毒なら当ると思う人もいるかもしれない。1文字追加すれば確率はその1/25になる。まずそのルートで試そうという攻撃者はいないだろう。

攻撃者の目線で見れば、ユーザーパスワードに対する攻撃が行える(=OSのログインサービスにアクセスできる)時点で他に取り得る魅力的な攻撃手段がある。ユーザーパスワードはそれらより魅力が劣る程度の耐久力があればいい。

閑話開始

試行というのは、パスワードを推測して、それが合っているか確認する作業のことで、完全なサーバの機能と対話して行う場合と、そのサーバが参照している正解のパスワードファイルを手に入れて行う場合がある。

正解のパスワードファイルがわかっているのになぜパスワードを推測する必要があるか。 パスワード保管のベストプラクティスに従っているなら、正解のパスワードファイルはパスワードそのものではなく、ソルトと共に鍵導出関数でハッシュ化された値だからだ。 鍵導出関数というのは、暗号論的に安全なハッシュ関数の、計算にかかる時間が長いバリアントのようなものだ。 計算にかかる時間が長ければ、単位時間当りの試行回数を少なくすることができ、ソルト(ハッシュ化する際に付加され、共に保管されるランダムな値)により、事前にハッシュ計算することが無効になり、個々のパスワード一つ一つに対して計算を行う必要がある。 せいぜい定数倍の改善なのでパスワードを長くすることには及ばないが、非安全なパスワードを使い回す人が、サービスの侵害でパスワードを保管したファイルが漏洩されたときに使い回している他のアカウントに不正アクセスされる可能性を減らすことができる。

あなたが最近のMacOSを使っているなら、ユーザーパスワードがディスク暗号化の鍵を兼ねている場合がある。 この場合もそこまで長くする必要はない。TPMの中に鍵があり、ユーザーパスワードはTPMと対話して鍵を出力させるためにあるだけで、その対話にレートリミットがあるからだ。

あなたがTPM, Secure boot, フルディスク暗号化, メモリ暗号化などを使って物理アクセス時の機密性に気を使っている場合も、ユーザーアカウントのパスワードで機密性を守ろうとせずにフルディスク暗号化の復号にTPM pinかパスフレーズを使用するべきだろう。TPMのレートリミットが突破されたら？確かにそういう例もあるが、TPMが信頼できないならそもそもTPMを使わなければいい。基本的に利便性のためにあるモジュールで、使わなければ攻撃面は増えない。この場合は秒間数億の試行を念頭に置くので長いパスフレーズが必要になる。