Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
「いいね！」 2
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
「いいね！」 9
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
「いいね！」 1
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
「いいね！」 2
これは私には理解できません（そのためスレッドを再浮上させました）。一度パスワードがクラックされた、あるいは平文で発見されたとわかれば、そのセキュリティは著しく低下します。非常に寛大な仮定を置いたとしても、これは巨大なエントロピーの減少を表します。
- 10 文字のランダムなパスワード（非常に限られた文字セットの場合でも、例として小文字のみ：確率 = 1/26^10 = 1/1.4e14）
- HIBP リストに含まれていることが知られているパスワード（確率 = 1/5e8）
他の誰かがそれを使ったかつ、それが漏洩または解読された場合が重要な違いです。
1 つのリストにのみ出現したパスワードを防止することの実践的な問題は何かありますか？ユーザーとして、そのパスワードを再使用しないようにするために、そのような情報を得たいと思うのは間違いありません。サイト管理者としても、ユーザーが侵害されたパスワードを使用することを望みません。これは、使い勝手のトレードオフに見合う価値があるように思えます。
いいえ、決定的な違いではありません。統計的には、すべてのパスワードは時間とともに侵害されるからです。
すでに最も一般的な100万個のパスワードをブロックしており、それは長年続けてきました。したがって、重要な点についてはすでに保護されています。
「いいね！」 3
統計的に見れば、すべての暗号化およびハッシュアルゴリズムも時間とともに破られます。アルゴリズムが破られつつあるという最初の兆候が見られた時点で、そのアルゴリズムの使用を中止します。
なぜパスワードだけが例外でなければならないのでしょうか？すべてのセキュリティは、与えられたタスクに対して使用されているエントロピーが十分であるという賭けであり、そこには常に耐えうる攻撃の長さや強度に関する前提が含まれています。
パスワードがリストに初めて現れる時点で、少なくともエントロピーが6桁（現実的にはさらにそれ以上）失われることを考えると、これは簡単な判断だと言えます。
はい、これは現在入手可能な多くの他のソフトウェアパッケージが存在する状況よりもはるかに良い状態です。HIBP（Have I Been Pwned）は、それに加えてさらに保証を望むサイトにとって、まだ大きな改善となります。
プラグインで「パスフレーズの生成」ボタンを追加する機会かもしれませんね（技術的に可能であれば）。
既知の漏洩リストにある単語は除外され、ユーザーは独自のパスフレーズを作成することもできます。これには「基本」の100万語除外リストが最初から組み込まれています。ボタン方式なら、ユーザーに漏洩リストやエントロピーについて説明する必要がなくなります。ユーザーは通常、そこまで時間を割くつもりはありませんから。
ただ、Discourse はすでに十分良い機能を備えていると思います。
なぜパスワードをサーバー側で生成するのでしょうか？
ユーザーがパスワードを保存する必要があると仮定すると、パスワード生成の責任をユーザー自身が管理する方が理にかなっているのではないでしょうか？ユーザーが選択する資格情報管理ツールは、おそらく既にこの機能を提供しています。
「いいね！」 2
「apple」「apple1」「apple 123」「apple 12345」などが、100 万個の禁止リスト（1m verboden list）に該当し、受け入れられないことを繰り返し伝えるよりも、サーバー側で生成する方がよい場合があるからです。私個人としては Discourse にこの機能を搭載するとは思いませんが、これで「ハッキングされたパスワード（pwned passwords）」の問題を比較的滑らかに解決し、万が一の問題発生時にはユーザーの判断に委ねられるのであれば、検討する価値があるかもしれません。
クライアントサイドのパスワードマネージャーがこのようなパスワードを生成するとおっしゃるのですか？
ユーザーにパスワードマネージャーの使用を推奨する方が、単一のサイトからパスワードを強制するよりもはるかに効果的です。後者は、そのパスワードを他の場所でも使い回すことにつながり、漏洩を加速させるだけです。
「バカを直す」のは、「乗っ取られたものを直す」より難しい。https://www.useapassphrase.com/ に似たものを手を取りながら使うことは、その仕組みの学術的側面に関心のない人々にとって、少なくとも一つの救いとなると思います。
私は数千万人の利用者が使用するシステムを構築してきました。パスワードに関連して、特定の文字や記号を必須とするような、あまりにもひどいアプローチを含むさまざまな手法を実証実験してきました。
ユーザーにパスワード管理について教育しない限り、パスワード疲れや使い回し、そして恐ろしい「キーボードの下に付箋を貼る」といった事態が起きる可能性が高まるだけです。
また、サーバー側でパスワードを生成すると、新たな攻撃ベクトルと保護すべき表面が生まれます。個人的には、上記のすべてをなくしたいと考えています。
「いいね！」 3
JS はクライアント側でランダムなパスフレーズを生成し、それをハッシュ化してリストと比較するだろうと思っていた。教育部分は「パスワードを作成」の上部にスタブを置くだけで十分だ。正直なところ、これらはいずれも Discourse が関与すべきことではないと思うが、人々が自身の行動に対する怒りをブランドのせいにしている限り、検討する価値はあるかもしれない。
それでは、あなたが提案する機能を実装するプラグインを開発するか、委託するのが最善策だと思います。
「いいね！」 1
それもまさにこのプラグインの目的です。
このプラグインを作成してから少し考えましたが、ジェフの意見に賛成です。
「侵害された」とは、どこかで誰かが「リスト」に表示されたそのフレーズを思いついたことを意味します。例えば、以下のようなツールを作成したと想像してください。
- 文字列のリストを公開する。
- 一意の文字列を体系的に生成してリストに追加する。
ジェフの主張は、このようにすれば最終的にすべての文字列が「安全ではない」となるということです。なぜなら、どこかの公開リストに出現するからです。やがて、あなたの「超安全な」パスフレーズもこの拡大し続けるリストに載ってしまうでしょう。
パスワードそのものの概念は、誰かがあなたのアカウントのパスワードを推測できないという「統計的な不可能性」に依存しているに過ぎません。攻撃者は技術的にパスワードを知る必要はありません。ただ非常に優れた推測をするだけでよいのです。彼らは「優れた推測」を意味するものを以下のように活用して有利に進めることができます。
- 侵害事例があれば、同じアカウントに同じパスワードを試す
- 侵害事例のリストがあれば、多くの人が使用しているパスワードを試す
Discourseが上記の#2に優れていることは既に議論済みです。あなたが狙っているのは#1だと考えられますが、これを実装するのは不必要であり、使い勝手が悪すぎます（ユーザー名に関連しない任意のパスワードを使用しないという前提の場合、コア機能として実装するのは…）。しかし、あなたのサイトであなただけが求める機能が必要な場合、このプラグインが最適です。
「いいね！」 4
はい。率直に言えば、これはひどい議論です。なぜなら、これは確率という、この問題について議論する唯一正しいアプローチから完全に切り離されているからです。
幸いなことに、私たちが話しているのは、最も一般的に使用されるパスワードを除外した後に残るごく一部のケース（エッジケース）に過ぎません。それだけで、すでにかなり効果的な戦略と言えます。
「いいね！」 1