ユーザー名のバリエーションに対するパスワード検証

貢献 特徴
1

直接の関係はありませんが、最近パスワードの強度検証について検討していることから、Pwned Passwords Validator の話題に触発されました。

Discourse は、ユーザー名 myusername に対して myusername123 や 4myusername のようなパスワードをブロックしていないようです。

この特定の種類の弱いパスワードに関する過去の議論は見つかりませんでした。以前に検討されたことはありますか？

「いいね！」 5
3

パスワード選択時に「パスワードにユーザー名の小文字版を含めない」というチェックを追加することに賛成です。それは妥当な対応だと思います。

4

すでに password = username のチェックは行っていますが、部分一致のチェック、特に短いユーザー名のケースではあまり好みません。ユーザー名が「Ed」で、パスワードにたまたま「ed」が含まれるランダムな文字列だった場合など、問題が起きる可能性があります。

「いいね！」 3
5

類似度スコア（レーベンシュタイン距離など）を使用して、levenshtein(username, password) < 6 の場合に失敗させるのはどうでしょうか。あるいは、置換も検出するために以下のような方法はいかがでしょうか。

levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6

これなら、最も悪質なケースをカバーしつつ、「Ed」というユーザー名で長いパスワードを設定することを禁止することにはなりません。また、「ユーザー名とパスワードが似すぎています」と正確に説明することも容易です。望ましくないエッジケースがないか確認はしていませんが、現時点では思い当たりません。

「いいね！」 3
6

今日の関連ツイート:

「いいね！」 5
7

「より多くのルール」という側面には、パスワードを総当たり攻撃しやすくなるという別の面もあります。

明らかに、15文字以下のパスワードに文字「z」が10回繰り返されるべきではありません。

明らかに、12文字未満のパスワードに「password」という単語が含まれるべきではありません。

辞書にある2つの単語が連続して並んでいるのも、明らかに間違いです。

などなど。つまり、パスワードを検索する空間が縮小されます。

これは沼のようなものです。昨日からこの件について考えており、考えを変えました。私は @codinghorror に同意します。ここでは何もしなくてよいと思います。

「いいね！」 3
8

「良いルールを作るのは難しいから、ルール自体を作るべきではない」ということですか？

これはここ2日間で、Discourse チームの高位メンバーがセキュリティに関する重大な誤解を広めているのを見た2度目です。いくつか一般的な点について再考が必要だと考えます。これを建設的なフィードバックとして受け止めていただければ幸いです。

また、この具体的な提案は突然出たものではありません。最近、ユーザー名が myusername で、パスワードが myusername46 という形式だったために、ユーザーアカウントが乗っ取られる事案が発生しました。

これは ClassicPress サイト（WordPress と同じログイン構造）だったため、ボットなどの対象としては「簡単に狙える的（ロー・ハンギング・フルーツ）」でした。しかし、ボットが狙うようなパターンでもあります。

パスワードの規則ではあらゆる種類の不適切なパスワードを防ぐことはできませんが、非常に大きな効果は期待できます。

9

技術的には、NIST 800-63-B のガイドラインに従っています。

メモリされた秘密の確立および変更に関するリクエストを処理する際、検証者は、一般的に使用されている、予想される、または侵害されていることが知られている値を含むリストと比較しなければならない。例えば、そのリストには以下が含まれる可能性があるが、これに限定されない。

  • 過去の侵害事例から取得されたパスワード。
  • 辞書に載っている単語。
  • 繰り返しまたは連続する文字（例：‘aaaaaa’、‘1234abcd’）。
  • サービス名、ユーザー名、およびそれらの派生語など、文脈固有の単語。

彼らは明確に「SHALL（しなければならない）」ではなく「MAY（してもよい）」という用語を使用しています。したがって、これは私たちの裁量に委ねられています。ここではLevenshtein距離に関する推奨事項はありません。「ユーザー名が6文字を超える場合、パスワードに含めない」といったルールや、100万パスワードリストに加えてエントロピーチェックを追加するといった対応も考えられますが、確定的な答えはありません。

もし独自のルールを強く望むのであれば、SSOを導入し、自社のエンドで任意のルールを設定するか、プラグインを開発することをお勧めします。

「いいね！」 3
10

おそらく、私たちもそれを行うつもりです。ここにはまだ不足している部分もありますが、これまでの反応を見ると、それを提起することに特に価値があるとは思えません。

11

作成したプラグインを、ここにある #plugin カテゴリのコミュニティで共有してください。私たちが下すすべての決定に全員が賛同するわけではありません。多様性や選択肢を私は完全に尊重しています。もしかすると、より厳格なパスワード規則に関心を持つ人もいるかもしれません。

「いいね！」 1