- NISTは「多様な文字種で構成されたパスワード作成要件」と「定期的なパスワード変更要件」を「禁止」する予定。これはサイバーセキュリティ上の弱点と見なされている
パスワード要件
- 検証者とCSPは、パスワードの長さが最低8文字以上であることを求める必要があり、最低15文字以上を要求することが望ましい SHALL
- 検証者とCSPは、最大パスワード長として少なくとも64文字以上を許容することが望ましい SHOULD
- 検証者とCSPは、パスワードにすべてのASCII印字可能文字とスペース文字を許可することが望ましい SHOULD
- 検証者とCSPは、パスワードにUnicode文字を許可することが望ましい。パスワード長を評価する際、各Unicodeコードポイントは1文字として数えられるべきである SHOULD
- 検証者とCSPは、パスワードに対して他の構成規則（例: さまざまな文字種の混在要求）を課してはならない SHALL NOT
- 検証者とCSPは、ユーザーに定期的なパスワード変更を要求してはならない SHALL NOT 。ただし、認証子の侵害を示す証拠がある場合、検証者は変更を強制しなければならない SHALL
- 検証者とCSPは、加入者が未認証の請求者にアクセス可能なヒントを保存することを許可してはならない SHALL NOT
- 検証者とCSPは、パスワード選択時に加入者へ知識ベース認証（KBA）または秘密の質問を使うよう促してはならない SHALL NOT
- 検証者は、提出されたパスワード全体を検証しなければならない（つまり、切り詰めてはならない） SHALL
その他の言及
- 既存ルールの問題点: 以前はUnicode文字が特定のプラットフォームで正しく保存されない問題があった。しかし現在では、Unicodeはより多くのエントロピーを提供する
- 新しい要件: 新しいNISTガイドラインには、任意のUnicodeを許可する要件が含まれる予定。これは国際化（i18n）をうたうソフトウェアに必須である
- パスワード構成ルール: NISTはパスワード構成ルールを「推奨しない」から「許可しない」へ変更。これはセキュリティ強化に向けた重要な一歩である
- 業界標準との衝突: 一部の業界標準（例: PCI、ISO 27001:2022）は依然としてNISTと相反する要件を持っている。これにより企業は新しいNISTルールに従いにくくなっている
- パスワードマネージャーの利用: パスワードマネージャーはWebサイトだけでなく多様なシステムで有用。ハードウェアトークンや生体認証を通じてマスターパスワードを入力する方法もある
- パスワード長の制限: パスワード長の制限は認証システムのリソース枯渇を防ぐためのもの。しかし、短すぎる制限はセキュリティに深刻な制約を与えうる
GN⁺のまとめ
- NISTの新しいパスワード規則は、従来の不要で有害なセキュリティ要件を取り除くことでセキュリティを強化する
- Unicodeパスワードの許可は、国際的なユーザーに大きな助けとなるだろう
- 一部の業界標準との衝突により、企業は新ルールに従うのが難しい可能性がある
- パスワードマネージャーは多様なシステムで有用であり、ハードウェアトークンを通じてセキュリティを強化できる
- パスワード長の制限はリソース枯渇を防ぐためのものだが、短すぎる制限はセキュリティ上の問題を引き起こす可能性がある。
14件のコメント
最大長が短いところは、ちょっと困りますね。
実際、パスワードは
ジョアペクパン0212341234ランチ特選1人前カードでお願いします
のように「既存の単語」の組み合わせであっても、いくつも連なると難易度が急上昇するんですよね。
私の会社でも今年初めに方針が変更され、英単語を4つ以上並べる方式に変わりました。
そのため、毎朝名言を打ち込みながら一日を始めています。
あの開発文化がまだましだと言われるCoupangでさえ、視覚的なフィードバックが一切ないまま、ひっそりとパスワードの長さを16文字に制限していました。パスワード変更メールも来ず、何の理由もなくログインできなくなったので、ハッキングされたのかと思いました
開発分野にもいろいろな領域があるからでしょうか。セキュリティやアクセシビリティは、あまり扱われていない代表的な分野のように思います。ダークパターンに注ぐ努力のほんの一部でも...
今確認したところ、上限が20文字に調整されていました。ですが、依然として会員登録のWebページでは、パスワードに関する案内文や視覚的なフィードバックが一切ないままパスワード長が制限されており、ログインのWebページでは何の制限もありません。一方、Androidアプリのパスワード変更ページでは、パスワードのルールが正確に明示されています。AndroidチームとWebフロントエンドチームの連携が取れていないようですね。
典型的なサイロ化の現象だと思います
何一つまともに守られていないですね…
これをご覧のUI担当者の方がいらっしゃれば、パスワード入力時に画面上に表示される仮想キーボードでの入力を強制するUIも、ぜひ廃止していただきたいです。
最初に登場したのは、パスワードがキーロガーによって漏洩するのを防ぐためだったのでしょうが、今ではあちこちにあるカメラに撮られてパスワードが漏れる危険のほうがはるかに大きいです。
見るたびに戸惑うUIなのに、いまだに維持されているのが不思議です。
おそらく、キーロガー対策で作られたということはすでに忘れ去られ、みんながそうしているからただ追随しているだけなのではないかと疑ってしまいます。
政府のセキュリティガイドだからです。仮想キーボードを入れたい企業は誰もいないでしょう。
各種標準認証にも仮想キーボードが必須事項になっているものが多いです。思った以上に細かな要求事項が多く、これを実装した既存企業の製品（SDK）を使わないと、審査に時間が余計にかかったり、却下されたりすることもあります。実際、これはセキュリティ企業のカルテルではないかと思えるほどです。
公的機関だけでなく、NAVERやCoupangのような技術系企業もそうしているので、なおさらもどかしいです。
あそこは政府からそうしろと命令されているから、しぶしぶ従っているだけではないでしょうか？
パスワードの最大長が12文字程度と短かったり、特殊記号を許可しないサイトは使うのをためらいます。セキュリティに気を配っていないことを示すサインの一つに見えます。
Hacker News の意見
NIST は2017年から、パスワード構成ルールを緩和するガイダンスを提供してきた
NIST 自体はポリシーを設定しないが、多くの他のポリシーが NIST 800-63 を参照している
Web サイト登録時に「良いパスワードには a、b、c を使わなければならない」というルールは非常にいら立たしかった
NIST は「秘密の質問」も禁止している（例: 「母親の旧姓は？」）
NIST は何十年もの間、誤ったパスワード指針を提供してきて、ようやく今になってより合理的な解決策へと変更した
bcrypt の問題により、「提出されたパスワード全体を検証しなければならない」という要件が生まれたようだ
NIST は最大パスワード長として64文字を提案している（多くのサイトは20文字に制限しており、パスフレーズの使用が不可能だった）
あるユーザーの話:
特定の文字を要求することがエントロピーを増やすのか減らすのかについて議論がある
NIST が平文パスワードを PAKE に置き換え、W3C がそのためのメカニズムを整備するのを待っている
元リンク: NIST SP 800-63b