Skip to content

パスワードベストプラクティス

この記事は https://docs.evolveum.com/iam/best-practice/password/ の翻訳です。

パスワードは、今でも memorized secret authenticator の最も一般的な種類です。 このページでは、パスワードの適切な利用に関する一般的な情報を提供します。

パスワードポリシー

パスワードの適切な利用に関する推奨については、サイバーセキュリティコミュニティの中で多くの不一致があります。 パスワード利用に関する伝統的な考え方は、できるだけ複雑なパスワードを使い、できるだけ頻繁に変更を強制するというものでした。 しかし、これは逆効果の助言であることが分かりました。 複雑なパスワードの要件は、ユーザーがパスワードを覚えることをほぼ不可能にし、パスワードを書き留めたり、複数のサイトで同じパスワードを再利用したりする動機になります。 さらに、頻繁なパスワード変更の強制は、予測可能なパスワードパターン につながり、実際のセキュリティ向上なしにユーザーへ不便を強います。

そのため、パスワードポリシーに関する推奨は、ここ数年でよりよいユーザビリティに向かって変化しています。 以下の推奨は、最近のセキュリティ標準（例: ISO/IEC 27002:2022）、ベストプラクティス（例: NIST SP 800-63B）、および経験に基づいてまとめたものです。 現在、次の対策を実装することを推奨します。

  • ユーザーが選ぶパスワードは少なくとも8文字、生成されるパスワードは少なくとも6文字にするべきです。
  • すべての printable（ASCII）文字とスペースをパスワードに使えるようにするべきです。 パスフレーズの利用を促すため、スペースを許可するべきです。 記号や類似の文字も許可するべきです。これらはパスワードマネージャーで一般的に使われるためです。
  • 推測しやすいパスワードや漏えい済みパスワードの拒否リスト（辞書）を適用するべきです。 また、パスワードにサービスデータやユーザーデータが含まれていないか確認してください。たとえばユーザー名、ユーザーの名または姓、サイトやサービスの名前、ユーザーの誕生日や生年に対応する数字の組み合わせ、電話番号などです。
  • パスワードの長さは、パスワードの強度を決める主要な要素と考えられます。 短いパスワードよりも長いパスフレーズの利用を推奨してください。 システムは少なくとも64文字のパスワードを許可するべきです。 極端に長いパスワードを使おうとするサービス拒否（DoS）を避けるため、制限を設けることは合理的です。 ただしパスワードの最大長制限はかなり高くするべきです（例: 3000文字）。
  • ブルートフォース攻撃を避けるため、認証試行の頻度を制限するべきです。 最善の方法は、複数回の失敗後にパスワードを一時的にロックアウトするか、失敗のたびに合理的な増分でロックアウト時間を徐々に増やすことです。 失敗のたびに強制的なロックアウト期間を設けると、通常はサービス拒否（DoS）攻撃の機会を作るため、推奨されません。
  • パスワード変更後にパスワードを確認するときは、曖昧な状況を検出してください。 たとえば印字不能文字の存在、連続する複数のスペース、パスワードの先頭または末尾のスペースなどです。 検出した場合、ユーザーに警告するか、パスワードを拒否してください。
  • 平文パスワードは絶対に保存しないでください。 常にパスワードをハッシュ化（かつソルト付与）した形式で保存するか、同等レベルの保護を提供してください。 これは攻撃時に少量の追加保護を提供します。 しかし、実装は比較的簡単であり、システム管理者にパスワードが意図せず露出すること（例: ログファイルやデータベース痕跡ファイル）に対してかなりの保護を提供します。
  • セキュリティインシデントの後、またはパスワードがもはや安全でないと検出された場合には、パスワード変更を強制してください。

パスワードを生成する場合:

  • パスワードではなくパスフレーズを生成してください。単語とスペースを使い、ほどよく長いランダムな文を形成します。
  • 二重スペースのような曖昧な並びを避けてください。
  • 非パスフレーズパスワードを生成する場合、誤りやすい文字を避けてください。たとえば 0（数字の 0）と O（英字の O）、1（数字の 1）と l（小文字の l）などです。 おおよそ同等のエントロピーを保つため、より長いパスワードを生成して補ってください。 これは、パスワードが印刷され、印刷物から再入力される可能性が高い状況（例: デバイスの初期パスワード）で特に重要です。
  • 短期または初期パスワードであっても、固定または予測可能なパスワードの利用は避けてください。 そのようなパスワードは一度設定されると、ほとんど変更されません。 初回ログオン時にパスワード変更を強制しても、ユーザーは元のパスワードの予測可能な変種を選ぶ可能性が高いため、状況は改善しません。 デバイスや本番サービスで固定の「工場出荷時」パスワードを使うことは絶対に避けてください。それらは大規模な自動攻撃にとって狙いやすい対象になるためです。 ユーザーの名前、誕生日、生年、類似データの利用も避けてください。それらは通常、ソーシャルエンジニアリングなどで非常に簡単に知ることができます。 固定かつ予測可能なパスワードは、リスクを強く制限するよう設計された追加のセキュリティ対策と組み合わせる場合にのみ使えます（例: 機密性の高いデータを持たず、localhost でのみ利用できるデモサービス）。

伝統的な考え方からすると、パスワード複雑性要件がないことは驚きかもしれません。たとえば大文字、小文字、数字、記号の組み合わせを要求することです。 このアプローチは効果的ではありません。 パスワードを非常に覚えにくくする一方で（ユーザビリティが低い）、セキュリティを大きく高めるわけではありません。 たとえば alice をパスワードに選ぶユーザーは、大文字が必要なら Alice、数字が必要なら Alice1、記号が必要なら Alice1! を選ぶ可能性が高いでしょう。 したがって、パスワード複雑性要件はよいセキュリティトレードオフではありません。

同様に、パスワードの有効期限やパスワードの定期的な強制変更の要件もありません。 パスワード変更を強制されると、ユーザーは元のパスワードの予測可能な変種を選んだり、他のサイトで使っているパスワードを使ったり、パスワードを書き留めたりする可能性が高く、全体的なリスクは低下するのではなく増加します。

PIN

個人識別番号（PIN）は、次の2つの点を除けばパスワードとほぼ完全に同じです。

  • PIN は通常、数字のみです。
  • PIN はしばしばランダム生成であり、ユーザーが選ぶものではありません。

PIN に関する推奨は次のとおりです。

  • PIN がランダム生成である場合、少なくとも6桁（文字）にするべきです。

パスワードの未来

パスワードに関する最良の推奨が、そもそもパスワードを使わないことであるのは、おそらく驚くことではありません。 キーストローク記録、フィッシング、ソーシャルエンジニアリング攻撃など、最も強いパスワードでも耐えられない攻撃があります。 強いパスワードであっても、漏えいしたパスワードデータベースに対するオフライン攻撃には非常に限定的な保護しか提供しません。 全体として、人間の性質と組み合わさると、パスワードは本質的に安全ではありません。

残念ながら、パスワードを完全に置き換える万能薬や簡単な解決策は、まだ見つかっていません。 しかし、パスワードを他の認証機構と組み合わせることで、かなり安全にする方法はあります。 たとえば多要素認証は、パスワードのセキュリティ上の不足を補うために複数の認証機構を使います。 また、公開鍵証明書（X.509）やパスキーに基づく認証など、パスワードの置き換えを目指す技術もあります。 しかし、これらの技術の多くは、PIN の利用など、パスワードに似た機構の一部を内部に含んでいます。

パスワードは少なくとも今のところ残り続けます。 予見可能な将来に「パスワードレス」になれるかどうかは、まだ明確な答えのない大きな問題です。

関連項目