概略

セキュリティの世界では、パスワードは依然として最も身近な認証手段です。しかし私たちが「安全なパスワード」として想像するものは時代や文脈によって大きく変わってきました。各種報道で昨今取り上げられているように、米NISTはパスワードガイドラインを 8月に改訂しています。本稿では、パスワードがどのように変わってきたのか、その変遷と現代におけるパスワードのあり方について考えてみることにします。

本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。

映画に登場したパスワード

古典的な映画を振り返ると、パスワードはしばしば物語を動かす小道具として使われます。こうした描写はフィクションであると同時に、当時の人々が「パスワードとは何か」をどう捉えていたかを映し出しています。

もっとも有名で古典的なパスワードは『アリババと40人の盗賊』に登場する「Open Sesame (開けゴマ)」と言えるでしょう。

東西冷戦時における軍事コンピューターの暴走を描いた『ウォー・ゲーム』(1983)では、主人公の学校のオンラインアクセスのパスワードが、職員室の引き出しの紙に書かれていました。そのパスワードは定期的に変更されていましたが、どうやら 6桁の単語が使われており、その時は「PENCIL」となっていました。また、北米航空宇宙防衛司令部(NORAD)の軍事コンピューターWOPRへのアクセスパスワードは、開発者の息子の名前「JOSHUA」でした。

事故によってロボットが意思を持ってしまう『ショート・サーキット』(1986) では、戦闘用ロボット S.A.I.N.T への遠隔ログインのために「4721」というアクセスコードをコンソールから入力しています。

ご存知『コマンドー』(1985)での武器庫を開けるための暗証番号は「13」というたった2桁のものでしたが、きっと一定以上の筋肉でなければボタンが押せない仕様なのだと信じています。

大作スペースオペラのパロディである『スペースボール』(1987)では、惑星を覆うシールドを制御するコード番号が「12345」という簡単なものでした。作中では「バカがトランクの鍵につける番号だ」と揶揄されており、想像がつきやすい簡単なパスワードが不適切であるという認識はある程度広まっていたとみられます。ところで、2027年には40年ぶりの新作『スペースボール2』が公開されるようで楽しみです¹ 。

このように1980年代の映画では、暗証番号と同程度のセキュリティか、視聴者に理解しやすい短い単語などが使われているケースが多いようです。加えて、これらの映画に登場するパスワード入力は共通して アカウントを指定する描写がありません。 パスワードだけでの認証が描かれており、その点において認証システムの成熟度はアリババの時代から進歩が無いとすら言えます。

1990年代に入ると映画の中でのログイン方法も変わり、パスワードのみでの認証ではなく、アカウント名(ログインID)の入力シーンが見られるようになります。『ユー・ガット・メール』(1998)では主人公やヒロインがインターネットメールを使ったやり取りをしていますが、その際に各自のアカウントでログインする様子が見られます。

『エネミー・オブ・アメリカ』(1998)ではNSA職員が入室する際にIDカードと指紋認証が使われており、より厳格なセキュリティが求められる場ではパスワード入力以外の認証が採られている描写もみられます。

2000年代に入り『ソーシャル・ネットワーク』(2010)や『Searching／サーチ』(2018) では、「MAURICE1985」や「margot0401」のように英文字と数字の組み合わせがパスワードに使われていました。これは当時推奨されていた、英数字と英文字の組み合わせで複雑なパスワードを利用しようという方針が影響していたと思います。フィクションの中では視聴者へのわかりやすさを重視してか、比較的簡単な文字列になっているようです。

暗証番号や合言葉と同じでアカウント制御の考え方に乏しかった80年代から、徐々にITが浸透していくなかでパスワードやログインの描かれ方も変わっていったように感じます。

現代のパスワードガイドライン

一昔まえのパスワードガイドラインでは 8文字や14文字以上などと記載しているものがありましたが、最近のガイドラインではパスワードの最小の長さは 14～15文字以上とされています。更に補足として、後述するパスフレーズに対応するためにできるだけ長い文字列をシステムは許容すべきという記述も見られます。

出典	パスワードの最小長	備考
CIS Password Policy Guide v21.12 (2021年12月)	14文字以上
NIST SP800-63B-4 (2025年8月)	15文字以上	システムは少なくとも64文字以上をサポートすべき
STIGs	14～15文字以上	OS等によって異なる²³⁴⁵

日本のガイドラインでは、具体的なパスワード長を定めていない表現も目につきます。インターネットの安全・安心ハンドブック Ver 5.10では「桁数が多い方が安全に資する」とし、政府機関等の対策基準策定のためのガイドラインでは「十分な長さと複雑さを有すること」とのみ記されています。これは古いガイドラインにあるような 8文字のパスワードを許容するものではありません。暗号鍵やその他の要素を用いるなど、 より強固な認証の必要性を説いており、単にパスワード長が何文字以上あれば良いという表現が行われていない のです。

強制ルールの落とし穴

現実のシステムでは、「英大文字・小文字・数字・記号を必ず含めること」といった複雑さを強制するルールが長らく推奨されてきました。しかし、実はこうした制約には副作用があります。

文字種による組み合わせの数

ASCII文字列に限定して組み合わせの数を考えてみることにします。

アルファベット大文字: 26
アルファベット小文字: 26
数字: 10
記号(印字可能な記号類): 32

使える文字種は 94種類となります。

これらを使って 4桁のパスワードを作る場合の組み合わせの総数は $94 ^ 4 = 78,074,896$ 通りあります。しかし「大文字・小文字・数字・記号を必ず1つずつ含む」という条件を課した場合には、各文字から1文字ずつ抜き出した組み合わせ $26 × 26 × 10 × 32 = 216,320$ の並び替えを考慮して $216,320 × 4! = 5,191,680$ 通りになります。見た目は「複雑さが増した」ように思えても、実際には総当たりに必要な総数は15分の1に減少してしまいます。

NIST SP800-63の草稿を書いたビル・バー(Bill Burr)氏⁶はウォール・ストリート・ジャーナルのインタビュー⁷ に対して「今では自分がしたことを後悔している」と述べ、英大文字・小文字・数字等の複雑な組み合わせを提言したことを悔いています。

攻撃者へのパターンの開示

ウェブサイトによっては、ユーザー登録の際に利用できるパスワードの条件を事細かに示していることがあります。例えば "パスワードは 8文字以上16文字以内" のように字数を示していることや、"パスワードに使える文字は英数大文字、数字、ハイフンのみ" のように使える文字種や記号を示している場合があります。

こうした情報は攻撃者にとっても有用で、条件に一致しないパスワードは試行する必要がなくなるのです。

パスフレーズという選択肢

辞書攻撃を防ぐために、パスワードには辞書に載っているような単語は使わないことが長らく推奨されてきました。しかし、それが文章になった場合には単純な辞書攻撃では突破できません。パスワードよりも長い文章(フレーズ)の方が良いという考えも広がってきています。

パスフレーズという言葉自体は、X.509証明書や、PGP秘密鍵などで使われていましたが、厳密に何文字以内がパスワードで、何文字以上がパスフレーズである、と使い分けていたものでもありません。

xkcdの風刺

2016年にランドール・マンロー(Randall Munroe)氏が描いた有名な風刺画として『Password Strength』があります。

Tr0ub4dor&3 はクラッキング・ソフトウェアにとっては簡単だが、人間にとっては覚えにくいので、モニターに貼り付けたポストイットにパスワードを書き留めるような安全でない習慣につながるからよくないとしています。一方、correct horse battery staple ⁸ のようなパスワードは、エントロピーが大きいためコンピューターには推測しにくいが、人間には非常に覚えやすいものとしています。

エントロピーとは結果の「不確実性」を表す尺度です。この文脈では、パスワードの次の文字がどれだけ予測できないかを表す値と考えることができます。風刺画では Tr0ub4dor&3のエントロピーは 28ビットであり、correct horse battery stapleのエントロピーは 44ビットとされています。このエントロピーの算出については批判的な意見もみられますが、十分な長さを持つ文章であれば、短い桁で複雑なものよりも強固となることについては一定の合意が得られているように思えます。なお、日本のNISCによると、パスワードエントロピーは「パスワードの解析にかかる試行回数」を示すとしています。エントロピーが 128ビットである場合には、2の128乗回の試行を要することになります。

さて、風刺画の中で弱いパスワードとして例示されている Tr0ub4dor&3 ですが、元の綴は Troubador(トルバドゥール)なのでしょうか。このようにアルファベットを数字や記号に置き換える技法を Leetなどと呼ばれますが、こうしたパターンはすでに攻撃者が把握しているものですので、ある意味で辞書に載っている簡単なパスワードになりがちだとも言えます。

最近の意見

2025年4月に投稿されたNISTの技術情報 How Do I Create a Good Password? ⁹ ではパスワードは少なくとも15文字以上であるべきだと推奨するとともに、複数の単語を組み合わせたパスフレーズを使えば長いパスワードを覚えやすくなると記載しています。一例として cassette lava babyという文を示し、18文字の長さで推測しにくいパスフレーズだと記されています。

2024年8月に投稿された Okta社の Password vs. Passphrase ¹⁰ という記事では、パスフレーズは長くランダムなフレーズであるべきだと述べられています。文法的に正しい必要もなく、記号やスペースを含む規則性の少ない文章であることを推奨し、一例として flew cat, bo0k through there! という文章が示されています。

このように単語を繋いだ文章(フレーズ)を用いることで、覚えやすく強いパスワードを作り出すことができるという考え方は古くからあり、徐々に広まっているように感じます。現時点でのシステムではパスワードの長さに制限があるものが多いので、すぐに実践できるものではないかも知れませんが、使えるケースならば実践してみてください。パスワードにスペースが使えないシステムもありますが、何も単語のつなぎがスペースでなければならないルールはありません。スペースの代わりにハイフンやカンマなどを単語の区切りに使っても問題はありませんし、日本人ならばローマ字を使っても構いません。

そしてパスキーへ

どれだけ覚えやすいものであっても、結局は人間の記憶に頼るには限度があります。

今後はより長い公開鍵暗号を用いるパスキーなどに移行していくことが予測されます。

パスキーの仕組み

パスキー(Passkeys)とは、パスワードに代わる新しいログインの仕組みです。従来のように「覚えて打ち込む文字列」を使うのではなく、公開鍵暗号という技術を応用して「鍵のペア」で本人確認を行います。

利用者があるサービスに登録するとき、スマートフォンやパソコンの中で自動的に「秘密鍵」と「公開鍵」が作られます。公開鍵はサービス側に渡され、秘密鍵は利用者の端末に安全に保存されます。この「公開鍵／秘密鍵」は相互に錠前と鍵のような関係にあり、一方を使って施錠したものは、もう一方でしか開けられません。

実際にログインするとき、サービスは「チャレンジ」と呼ばれるランダムなデータを利用者に送ります。利用者の端末は秘密鍵でそれに電子署名を行い、その署名を返します。サービス側は登録済みの公開鍵を使って署名を検証し本人確認ができます。ここで重要なのは、秘密鍵そのものは端末から出て行かないということです。つまり、パスワードのように入力欄から盗まれる心配がありません。

また、秘密鍵を使う際には必ず指紋認証や顔認証、あるいは端末のPINコードで利用者が本人であることを確認します。これによって、もし端末を盗まれても簡単に使われることはありません。よくある誤解として、パスキーは生体認証であるという説明を目にしますが、あくまでデバイスに保存された秘密鍵の利用のために生体認証を用いているもので、ログイン自体に生体認証を使っているわけではありません。

パスキーとドメイン

パスキーの仕組みにはもうひとつ重要な要素があります。それは「どのサービスの鍵なのか」を区別するために、ドメイン名が利用されているという点です。公開鍵は「example.com のアカウント用」といった形で、特定のウェブサイトやアプリに結びついて保存されます。つまり同じユーザーが複数のサービスを利用していても、それぞれ別々の公開鍵が発行され、相互に使い回されることはありません。

この仕組みはセキュリティ上大きな利点をもたらします。フィッシングサイトのように本物そっくりに見える偽サイトであっても、ドメイン名が異なる限り、登録されている公開鍵は存在しません。したがって、秘密鍵による署名は成立しません。また、フィッシングサイト側に秘密鍵や公開鍵の情報が渡ることもありません。これがパスキーが「フィッシングに強い」と言われる理由のひとつです。

しかし裏を返すと、サービスの運営者が不用意にドメイン名を変更すると、利用者が保持しているパスキーは別のサイトのものと見なされ、ログインできなくなります。ユーザーからすると突然使えなくなったように見え、再登録やサポート対応が必要になり、大きな混乱を招きかねません。

したがって、パスキーを導入・運用する側は、ブランド名やURLの変更を軽く考えるべきではありません。ドメイン名は鍵と紐づいた認証のプロセスに欠かせない要素になるからです。安易なドメイン変更はセキュリティとユーザビリティの両面で大きなリスクになることを理解しておく必要があります。

パスキーにおける注意点

いかにパスキーと言えども、認証後のセッションが窃取されてしまうと、攻撃者はそのセッションを使って本人になりすませてしまいます。これはセッションハイジャックと呼ばれる攻撃で、XSS(クロスサイトスクリプティング)や、悪意あるブラウザ拡張機能、改ざんされたアプリなどによって発生し得ます。つまり、パスキーは「ログイン時のなりすまし」には強力ですが、ログイン後の操作そのものを保護する仕組みではないことを理解する必要があります。パスキーを利用していても、むやみに不審な拡張機能を入れたり、怪しいリンクや添付ファイルを開いたりすることは避けるべきです。

また、サービスによってはパスキーと併せてパスワードやメールによるリカバリー(復旧チャネル)が用意されていることがあります。攻撃者はこの「別の入り口」を悪用しようとすることがあります。たとえば、契約者サポートを装った電話やメールで復旧用のログイン用のコードを聞き出す、アカウント復旧メールを盗聴するといった手口が存在します。復旧時以外でも、パスキーによるログインと従来のパスワード方式でのログインが併用されている場合は、従来の方法でのログインの悪用も考えられます。

一方、サービスを提供する側にも注意すべき点があります。

第一に、パスキーは「ログイン情報を盗ませない」点では優れていますが、サービスへの侵害や権限昇格の脆弱性を防げるわけではありません。たとえ利用者の本人確認がパスキーで完全に行われていたとしても、サーバー側のアプリケーションが侵害されてしまえば、利用者データは危険にさらされます。

また先述の通り、パスキーはドメイン名と強く結びつくため、サービスのブランド変更やインフラ構成変更に伴うドメイン変更は、ユーザーの既存パスキーを無効化し、ログイン障害を引き起こします。ユーザー体験が著しく損なわれ、問い合わせ・再登録が発生し、運用者側の負担が増大することにつながります。

最後に

パスワードの歴史を振り返ると、物語の合言葉から始まり、映画で描かれた単純なキーワードや暗証番号を経て、現代の複雑さと長さを意識したパスフレーズへと進化してきました。そして今、公開鍵暗号を基盤としたパスキーのように、人間が覚える負担を減らしつつセキュリティを高める仕組みが実用化されています。

重要なのは、規格やガイドラインの更新をただ追うのではなく、その背景にある考え方を理解し、自分や組織に合った運用を選ぶことです。パスフレーズを採る場合でもパスキーへ移行する場合でも、覚えやすさや使いやすさと攻撃への強さを意識するのが肝心です。

ここでひとつ強い注意点です。NIST や啓発記事、ブログ、風刺画などで公に例示されているパスフレーズ(たとえば correct horse battery staple のような有名例)は、すでに広く知られており、攻撃者の辞書に組み込まれている可能性が高くなります。したがって、それらをそのまま流用してはいけません。公的な例は「どのような形式が良いか」を示す学習用の素材であり、そのまま自分の鍵にすると弱点になります。

明日からすぐに取り入れられる実践的な工夫はいくつかあります。たとえば次の3つは手軽で効果的です。

自分にしか分からない関連性で単語を3〜4個つなげる (文法的に正しくある必要はない)。
サービスごとの使い回しはやめ、パスワードマネージャーで各サイト固有のパスフレーズを管理する (パスワードマネージャーの取り扱いは厳重にする)。
サイトが許すなら空白や記号で語を区切り、視認性を高める (ただし例示された文言は避ける)。

脚注

『スター・ウォーズ』伝説パロディ『スペースボール2』いよいよ撮影開始、「本当に実現するなんて」 (THE RIVER, 2025年9月9日) ↩
STIG Microsoft Windows Server 2022 Security Rquirements Guide 2025年2月版では 14文字以上と記載 ↩
STIG Microsoft Windows 11 Security Rquirements Guide 2025年2月版では 14文字以上と記載 ↩
STIG Red Hat Enterprise Linux 9 Security Rquirements Guide 2025年2月版では 15文字以上と記載 ↩
STIG Network Device Management Security Rquirements Guide 2025年2月版では 15文字以上と記載 ↩
NISTの元職員であり、同名のコメディアンとは別人 ↩
The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d! (2017年8月7日) ↩
RFC7997 表3 にパスワードの例として "correct horse battery staple" という記載があります。 ↩
How Do I Create a Good Password? (NIST, 2025年4月28日) ↩
Password vs. Passphrase: Differences Defined & Which Is Better? (Okta, 2024年8月29日) ↩