トピック
パスワードはとにかく長ければ良い 「新常識」をNISTガイドラインで確認する
2025年12月23日 08:20
証券会社の口座への不正アクセスでは、数カ月で7,000億円を超える被害が発生した。この証券口座乗っ取りでは、フィッシング攻撃によってパスワードが盗まれて不正アクセスされた例が多いと見られている。
パスワードが盗まれないようにするには、パスワードが盗まれてもアカウントを安全に守るためには、どんな対策が必要だったのか。そんなガイドラインを取りまとめているのが、米NIST(国立標準技術研究所)だ。
7月に公開された最新のガイドラインでは、安全なパスワードの作り方やパスワードよりも安全な認証の方法などがまとめられている。その中では、「パスワードの定期的な変更の強制は禁止」、「文字種の混在を強制してはならない」、「『秘密の質問』の禁止」など、慣習的に使われてきたパスワードについてのルールを「禁止すべき」と提言していることでも注目を集めている。パスワードマネージャーについても「利用を許可すべき」としている。
今回、このNISTのガイドラインを紐解いてみたい。なお、本文ではNISTのガイドラインに従って記載しているが、あくまで「米国のガイドライン」であり、強制力や罰則はない。
大幅改定から8年、現代事情に即したガイドラインへ
NISTが長年まとめているこのガイドラインは、「NIST Special Publication(SP) 800ｰ63」。最初のバージョン1.0が発行されたのは2004年6月で、当初は「電子認証ガイドライン」とされていた。これは2004年9月と2006年4月にアップデートされ、2011年12月には改訂版の第1版となる「NIST SP 800-63-1」が発行された。
続いて2013年8月には改訂第2版となる「NIST SP 800-63-2」が登場。2017年6月には改訂第3版「NIST SP 800-63-3」がリリースされた。ここで初めて「デジタルアイデンティティガイドライン」と文書名が変更された。さらにA、B、Cという3つの付属文書が追加された。付属文書Aは「登録と身元確認」、Bは「認証とライフサイクル管理」、Cは「フェデレーションとアサーション」について言及されている。これがほぼ刷新と言える大幅なアップデートで、この段階で様々な規定が定められている。
このSP 800-63-3は、2017年12月と2020年3月にアップデート。そして2025年7月に登場したのが、最新の改訂第4版となる「NIST SP 800-63-4」だ。以前と同様、デジタルアイデンティティガイドラインの名称は変わらず、A、B、Cの3つの付属文書も刷新された。
細かい点だと、A文書は「身元確認と登録」、B文書は「認証と認証器管理」、C文書は「フェデレーションとアサーション」となっていて、一部変更されている。
このSP 800-63-4は、「デジタルアイデンティティ」を安全に管理するためのガイドラインとして位置づけられており、リスクに応じた対策を行なうリスクベースのアプローチを推奨する。常に厳格なセキュリティが求められるのではなく、リスクの大小によって対策を選択するというのが前提とされている。
第4版で新たに導入されたのが、この「デジタルアイデンティティリスク管理(DIRM)」という考え方。リスクは動的で常に変化しているという観点が必要で、障害者、高齢者などを問わず、多様な利用者に対して公平であることが求められた。これは、例えば「最新スマートフォンがログインには必須」ではなく、その代替手段を用意すべきという考え方だ。
DIRMでは、オンラインサービスには2つのリスクがあるとしており、なりすましや詐欺などで受ける損害と、正当なユーザーが排除されたり、プライバシーが侵害されたりするリスクという考えが示されている。その中で、「デジタルアイデンティティの保証レベル」(xAL)が定義されている。
これは、「身元確認の保証レベル」であるIAL(Identity Assurance Level)、「当人認証の保証レベル」であるAAL(Authenticator Assurance Level)、そして「フェデレーションの保証レベル」であるFAL(Federation Assurance Level)の3つの保証レベルを指している。
ここで例えば、AALにおいてパスキーなどのように秘密鍵を複数端末で同期できる認証器が正式にサポートされた。ちなみにパスキーはAAL2では利用が許可されており、「フィッシング耐性があり、リプレイ攻撃耐性がある」という評価になっている。AAL3の場合、秘密鍵がエクスポートできることが認められないため、同期パスキーはAAL3としては認められない、といった具合だ。
大きな変化としては、身元確認の保証レベルであるIAL1では、従来「身元情報は自己申告のみでOK」だったが、新版では一定強度の身元確認が必要とされた。例えばオンラインサービスのユーザー登録で、氏名、住所、生年月日を入力させた場合、政府発行の身分証明書などを使った証明が必要となった。この場合、「ある程度の検証」とされているため、運転免許証の写真を送信する、といったレベルが想定される。
つまり、今までIAL1とされていた自己申告のみの身元情報はIALとしては扱われず、仮に自己申告であっても、その情報は検証される必要があるという定義だ。従来の未検証で自己申告のみというのは、IALなしという位置づけになった。
このxALを含めてそれぞれ身元確認、当人認証、フェデレーションに関して、詳細が付属文書で説明されている。
パスワードはとにかく長ければ良い――パスワードの新常識
その中で話題性が高いのが、付属文書B(SP 800-63B-4)「認証とライフサイクル管理」において言及されている「パスワード」だ。これは、サービス側がユーザーに対してどのようなパスワードを設定させるか、どのようなパスワードのポリシーであれば、セキュリティと利便性のバランスが取れたものになるか、といったものを示すガイドラインになっている。
この付属文書Bは、ネットワーク経由での「認証」に焦点を当てたもの。その中にパスワードの項目があり、詳細が定義されている。
この文書では「パスワード」となっているが、以前の版では「記憶された秘密(Memorized Secret)」という名称になっていた。いわゆるパスワード以外のパスコードや暗証番号、秘密の質問など、記憶認証にまつわるものが複数あったからだろう。ただ、この名称が広まらなかったためか、この第4版では名称がパスワード(数字のみの場合はPIN)に戻されている。
このパスワードに関してガイドラインは、事業者側がパスワード作成に関して定めるべき要件を指定している。
- 1:文字数の長さの要件。多要素認証ではなく、単一要素での認証の場合、パスワードの長さは最低15文字以上
- 2:多要素認証の場合、パスワードの長さは最低8文字
- 3:パスワードの最大の長さは、最低でも64文字を許容しなければならない
この3つはパスワードの文字数を指定したもの。パスワードだけでログインを認める場合は、最低15文字から64文字以上を許容すべきとなっている。これは「最長64文字まで」ではなく「少なくとも64文字」なので、「15～32文字」は許容されない。「15～100文字」はもちろん問題ない。長文になりがちなパスフレーズを許容するためとされている。
例えばパスフレーズは「konopasuwa-dohatyoukyouryokude-mojisuugatyounagainode-daremoyaburenainichigainai(このパスワードは超強力で文字数が超長いので誰も破れないに違いない＝80文字)」といった文章によるもので、より長文のパスワードを作成できて、安全で覚えやすいとされている。これも最大文字数が少ないと使えなくなるため、パスフレーズの利用が進まない原因になる、というのがNISTの考えのようだ。
この3つに関しては、旧版が単一要素でも最低8文字だったのが15文字になったのが変更点だ。
- 4:文字種の混在を強制してはならない。パスワード作成において、大文字・小文字・数字・記号の混在を強制することは禁止
- 5:すべての印刷可能なASCII、スペース、絵文字を含むUnicodeをパスワードとして受け入れるべき
この2つはパスワードの文字種を指定したもの。4番目は特によく言われる、「複雑なパスワード」を否定するものだが、実は以前からすでにこの混在の強制は否定されていた。「混在を強制すべきでない」となったのは、2017年6月のSP 800-63-3の時点で、長期にわたってNISTのガイドラインとして言及されていたが、「複雑な方が安全」と長きに渡って神話として語り継がれていた項目だ。
ただ、SP 800-63-3では、混在の強制は「SHOULD NOT」(すべきではない)という、どちらかと言えば「推奨されない」というニュアンスだったのに対して、SP 800-63-4では、「SHALL NOT」(してはならない)となり、明確に「禁止」となった。ちなみにガイドラインでは、すべての文字種を受け入れることを求めている。これも以前から同様の「禁止推奨」だが、よく見かけるような「パスワードに使える記号」を限定することは許容されていない。
いずれにしても、現在でも文字種を強制するサービスは多く、例えば「パスワードの長さは最長12文字で、英数字・記号を必ず使用する」といったNISTのガイドラインに完全に反しているようなサイトも多い。
- 6:定期的な変更の強制は禁止
- 7:パスワードのヒントの禁止
- 8:「秘密の質問」の禁止
定期的な変更を強制することも禁止されている。これもSP 800-63-3の時点で「禁止(SHOULD NOT)」となったが、SP 800-63-4では、さらに明確に「禁止(SHALL NOT)」になった。これに関しては、例えば総務省の「国民のためのサイバーセキュリティサイト」でも「定期的な変更は不要」とされ、比較的浸透してきているが、それでも現在でも定期的な変更を求めるサービスは存在する。
定期的な変更の強制は、むしろ簡単なパスワードを設定してしまう懸念があるためで、ガイドラインではパスワード漏えいなどの事実がない限りは変更を強制してはならないとしている。
パスワードのヒント、秘密の質問は、いずれも秘密になっておらず、利便性よりも安全性に対するインパクトが高いので禁止とされた。パスワードのヒントは通常平文で保存され、例えばヒントが「パスワード」だったら「password」だと推測される、といった具合に、ヒントというよりも正解を書いてしまうユーザーが出てきてしまう。秘密の質問も、今やネットを検索すれば情報が出回っており、一度漏えいすると変更できない(「母親の旧姓」は変更できない)ため、安全性が低い。こうしたことから、パスワードのヒントや秘密の質問は旧版から明確に「禁止(SHALL NOT)」されている。これらは旧版から変更されていない。
- 9： パスワードマネージャーの利用を許可すべき
- 10：パスワード入力欄への貼り付けを許可すべき
- 11：ブロックリストを照合しなければならない
これも大きな変更で、旧版でもパスワードマネージャーや自動入力(オートフィル)機能に関して推奨とまでは言えず、「パスワードマネージャーの使用を明示的に推奨していないが、貼り付け機能の使用を許可することを推奨」とされていた。新版では、サービス側は「パスワードマネージャーと自動入力機能の使用を許可しなければならない」と義務付けられた。パスワードマネージャーなどが使えない場合は、「貼り付け」機能によってその代用となることも義務付けられている。
インターネットのサービスが増え、サービスごとに異なるパスワードをすべて記憶することが不可能になった現代において、パスワードマネージャーの利用を禁止するまたは利用できないような設計にするのはナンセンスだ。サービス側はパスワードマネージャーが使えることを検証すべきで、明示的な禁止はもってのほか。もちろん、パスワードの貼り付け機能をオフにするような設計も禁止とされる。
ブロックリストは、「辞書に掲載されている単語」や「すでに漏えいしたパスワード」といった危険なパスワードをリスト化し、パスワード作成時に検証するというもの。パスワードの長さや複雑さを検証するサービスは存在するが、必要なのは複雑さではなく長さと単一性で、15文字以上で漏えいしていない辞書にも載っていない唯一の文字列が必要となる。
ガイドラインでは、このブロックリストのチェックは、パスワード全体で照合するとあり、「漏えいしたパスワードが含まれている」ではブロックすべきではない。チェックするのは、過去に漏えいしたパスワード、辞書に掲載されている単語、そのサービスのサービス名やユーザー名などの関連単語とされている。
このブロックリストの照合は旧版でも義務付けられていたが、これまで対応しているサイトはあまりなかったようだが、今回のガイドラインを踏まえると、文字種を強制してチェックするなら、ブロックリストと照合すべきとなる。これも旧版と変更はない。
今回のSP 800-63-4では、従来のガイドラインをさらに現代の状況にあわせて多要素認証を踏まえた点、パスワードマネージャー対応を必須化した点など一部の変更はあるが、一新されたというほどではない。ただ、現状に至ってもガイドラインに適合していないようなサイトは多い。NISTのガイドラインは強制力のあるものではないが、ユーザーの利便性とセキュリティのバランスを取った内容になっていると考えられ、その点を踏まえて自サービスを見直してガイドラインに従うことが推奨される。
なお、サービス側に対しては、パスワード保存で適切なソルト処理、パスワードハッシュ化が必須で、総当たり攻撃対策のために認証試行回数の制限が必要など、適切な管理も求められている。
ユーザーが手入力しなくても安全な認証方式＝フィッシング耐性
こうしたパスワードは、当人認証の保証レベルとしてはAAL1(パスワード単体での認証)であり、最もレベルが低いという扱いになっている。特にパスワードは「フィッシング耐性がない」という点が問題で、安全性に関しては低い認証方式という扱いだ。
このAAL1に含まれるのはパスワード、乱数表、アウトオブバウンド(SMSで送信されるPINなど)、単要素OTP(スマートフォンアプリで生成されたOTP/ワンタムパスワード)、多要素OTP(PINや生体認証でアクティベーションが必要なOTP)などが含まれる。
AAL1でも多要素認証は提供可能で、「その使用を推奨すべき」となっている。AAL1のポイントは、フィッシング耐性、リプレイ攻撃耐性が要求されないという点で、攻撃には脆弱な面があるということ。そうした点を踏まえて、サービス側は保証レベルに合わせた認証を要求することになる。
パスワードの要件が単独だと最低15文字になった代わりに、多要素認証と併用する場合は最低8文字から認められる点は、多要素認証、特にパスキーなどを利用することを想定しているようだ。
SP 800-63-4では、「フィッシング耐性」が重視されている。
当人認証保証レベルAAL2では、旧版が「推奨」だったフィッシング耐性が、「提供義務」になった。AAL2では、「少なくとも1つのフィッシング耐性のある認証オプションを提供しなければならない」と義務付けられた。あくまでオプションなのでユーザーが選択しない可能性はあるが、提供自体は「必須」だ。
このフィッシング耐性がない認証方式とは、パスワードやOTP、乱数表などだが、総合して「ユーザーが手入力する認証方式」と考えられる。手入力が発生するものはすべてフィッシング耐性がないというのが大前提だ。その上で、フィッシング耐性というのは、ユーザーの警戒心に依存せずに、つまりユーザーが注意しなくても安全にログインできる仕組みとされる。
「ログインするにはURLを確認しましょう」といったような注意をしなくてもログインが安全に行なえるのがフィッシング耐性があるという認証方式だ。
これを実現する認証方式としてはチャネルバインディングと検証者名バインディングがある。この例として扱われるのがパスキーで、NISTのガイドラインに言及はないが、日本で言うマイナンバーカードを使った当人認証もこれに当てはまる。
パスキーには2種類あり、秘密鍵をクラウド経由で同期して複数のデバイスで利用できる「同期パスキー」と、秘密鍵が端末から外に出ない「デバイス固定パスキー」で、いずれもSP 800-63-4で機能が明記され、いずれもフィッシング耐性のある認証方式として認められた。パスキーはドメイン名にもとづいて動作するため、偽サイトでは認証が動作しない。どれだけURLが似ていようとも、見た目が似ていようとも、そもそもパスキーの認証画面にならないのでログインが行なえない。
AAL2では、端末内に保管した認証情報の出力にも対応しているため、端末間で同期できる同期パスキーも認められるようになった点もポイントだ。AAL3ではハードウェアベースでフィッシング耐性が必須になっており、さらに同期が認められないため、同期パスキーは不可となる。
これに対してAAL3では、秘密鍵がデバイスからコピー・エクスポート・同期ができないこと、特定のハードウェアを物理的に持っていないと認証できないことが必須となっている。これは、セキュリティキーなどを前提とした要件だが、デバイス固定パスキーも条件としては当てはまるため、AAL3として位置づけられると考えられる。また、日本ではマイナンバーカードの当人認証もAAL3に当てはまる。
日本ではSP 800-63-4も踏まえた形で、「DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」をデジタル庁が発行している。
当人認証保証レベルやフィッシング耐性など、SP 800-63-4と同様の内容になっており、日本語として分かりやすく、デジタル庁なので日本の事業者であればより参考になるだろう。
また、デジタル庁ではDS-511に関する解説書であるDS-512を作成中で、こちらは2025年度内の公開が目標とされている。NISTではSP 800-63-4のFAQなどの公開が遅れている模様で、こうした文書が公開されればさらなる詳細が判明する。SP 800-63-4にしかない要件もあるので、どちらも参考にして、より安全で、より使いやすいサービスの提供を検討するのが良さそうだ。