🔑

2025/10 最新のパスワードポリシー「Special Publication 800-63B」が定義する、最適なパスワード

に公開
Security
パスワード
情報セキュリティ
idea

はじめに

2025/10/20、アメリカ国立標準技術研究所 (National Institute of Standards and Technology)　が最新のパスワードポリシー NIST Special Publication 800-63B(以下 800-63B)を公開しました。

以前まであった「パスワードは大文字小文字、記号が混在しなければならず～」のような慣習が明確に すべきではない と定義されるなど、かなりアップデートを要するものとなっています。

本記事では、最新のパスワードポリシーへのキャッチアップをしていきたいと思います。

ちなみに、800-63B では「そもそも認証とは何なのか」や「ログインセッションの有効期間は」といったような、認証認可に関する幅広い話題にも触れていますが、今回は「パスワード」にのみ絞って記事を書いています。

パスワードに関する原文を読みたい方は、こちらから直接閲覧いただけます。

TL;DR

  • パスワードは8文字以上。文字種の制限・制約は可能な限りしない
  • パスワードの定期変更などはシステムからは要求しない
  • その代わり、安易なパスワード・漏洩されたパスワードは可能な限りはじく

パスワードのポリシーについて

800-63B では、パスワードの入力時に行うべきことと、パスワードの検証時に行うべきことで項目を分けています。

パスワード入力

800-63Bでは、以下以外の複雑さを課すべきではない[1]としていますので、パスワード作成時には以下の要件のみを実装すれば十分かと思います

パスワードの長さ

  • 🔒ユーザが作成する場合は、 8文字以上
  • 🔒クラウドサービスプロバイダなどによって自動生成される場合は 6文字以上

パスワードの文字種

  • クラウドサービスプロバイダなどによって自動生成される場合は すべてが数字でも許容してよい(訳注: ユーザ自身が作成した場合でも、許容してもよいという記述になっていそう)

侵害されたパスワード

  • 🔒クラウドサービスプロバイダなどによって、漏洩されているなどの理由でパスワードが拒否された場合、別のパスワード作成を要求する

パスワード検証

パスワードの長さ

  • 🔒ユーザが作成する場合は、 8文字以上
  • 🔒クラウドサービスプロバイダなどによって自動生成される場合は 6文字以上
  • 入力されるパスワードは、64文字以上を受け入れられる
  • Unicode文字を許容するとき、各コードポイントは1文字としてカウントされるべき

パスワードの文字種

  • すべてのASCII文字種とスペースを許容するべき
  • Unicode文字を許容するべき
  • 異なる文字種の混在を要求したり、文字の繰り返しを禁止したりなどの規則を課すべきではない

パスワードの自動生成

  • 🔒 クラウドサービスプロバイダや検証者(システム)によってパスワードを自動生成する場合、承認された乱数ビット生成器(HMAC_DRBGなど)によって生成されなければならない

パスワードの検証時正規化

  • Unicode文字を許容するとき、NFKCまたはNFKDによる正規化を行うべき
  • 入力ミスを防ぐため、検証前にパスワードの連続するスペースを単一のスペースに置き換えてもよい。ただし、この操作の結果のパスワード長が8文字未満の場合は、この操作を行ってはならない。

ユーザへの通知

  • Unicode文字を許容するとき、ユーザーに対して「Unicode文字がパスワードに含まれる場合、環境の差異により認証が失敗する可能性がある」旨を伝えるべき(HMAC_DRBGなど)

禁止事項と制限

  • 🔒 認証されていないユーザーが閲覧することのできる 「ヒント」を保存させてはならない。
  • 🔒 パスワードの種類（例えば、「あなたの最初のペットの名前は？」など）を表示し、特定のパスワードの入力を要求してはならない
  • 🔒 パスワードの設定・変更の際は、一般に使用・予測されやすかったり、侵害されたことが知られているもの（過去の侵害コーパス、辞書、サービス名、繰り返し文字などのリスト）と比較し、該当すれば、拒否の理由とともに異なるパスワードの入力を要求しなければならない

入力欄

  • 🔒 パスワードの入力時、ペースト機能を使用できるようにしなければならない。パスワードマネージャの利用が容易になり、より強力なパスワードを使用する可能性が高まる
  • 入力を送信するまで、入力されたパスワードを******などで代替せずに直接確認できるオプションを提供すべき。
  • 正しい入力の支援のため、それぞれの文字の入力の後、その文字をマスクせずに表示する機能を実装してもよい。モバイル端末で特に有効

パスワードの変更について

  • パスワードの変更を、恣意的（例えば、定期的）に変更するように要求すべきではない。
  • 🔒 パスワードの侵害・漏洩の証拠がある場合は、パスワードの変更を要求しなければならない

推奨事項

  • パスワード強度メーターなどを表示すべき。特にこれは、「予測されやすいパスワードを拒否されたあと、ちょっぴり変更してリストから逃れる」ような変更を防ぐために重要
  • 🔒 認証失敗回数を効果的に制限する、CAPTCHAやIPアドレスなどによるレートリミットを設けなければならない

システムセキュリティ

  • 🔒 盗聴や中間者攻撃から保護するため、暗号化や認証済みのネットワークを用いなければならない
  • 🔒 パスワードは、オフライン攻撃に耐性のある形式で保存しなければならない

ハッシュについて

  • 🔒 パスワードは、適切なハッシュ関数(PBKDF2やBalloon など)とソルトを用いてハッシュ化されなければならない。ハッシュ関数は、パスワード、ソルト、コスト係数を受け取り、ハッシュを生成する。ハッシュの目的は、ハッシュファイルを入手した攻撃者によるパスワード推測のコストを高く、あるいは事実上不可能にするため。
  • 攻撃者のコストを高くするため、メモリハード関数を使用すべき
  • 🔒 ハッシュ関数は、HMAC, SHA-3, CMAC, KMAC, cSHAKE, ParallelHash などの、承認されたものを用いなければならない
  • 保存されるハッシュ長は、ハッシュ関数の出力と同じであるべきである(訳注: ハッシュ値を下手にいじるなという意図でしょうか)
  • 🔒 ソルトは最低32bit以上の長さを持ち、ほかのパスワードに用いられるソルトとの衝突が最小となるようにしなければならない
  • ハッシュコストは性能が許容する限り大きくすべきであり、例として、PBKDF2などでのコスト要因である反復回数は、一般的に10,000回以上とすべきである

追加ハッシュについて

  • 上記で導出したハッシュ値に対して、さらに別のソルトを加えたうえで、追加のハッシュ処理を加えるべきである。
  • 🔒 もしこの処理を加える場合は、追加のソルトは SP 800-90Ar1 で定義されるような 承認された乱数ビット生成器によって生成された、SP 800-131Aの最新版で定義される制定減のセキュリティ強度(現時点では112ビット)を満たす乱数である必要がある。
  • 🔒 この追加ハッシュで用いるソルトは、ハッシュ化されたパスワードと別の場所に保存されなければならない(例えば、ハードウェアセキュリティモジュールなどの専用のデバイスなど)。この処理により、このソルトが奪取されない限り、ハッシュに対する総当たり攻撃は不可能になる
脚注

  1. Appendix A. ↩︎

Discussion