bcryptを使用するときに選択するパスワードの最大長は？
KeePassを使用してGitHubのパスワードを生成すると、GitHubサイトでパスワードの長さの制限が72文字であるというメッセージが表示されました。 2の累乗ではないのは奇妙に思えたので、少しググってみたところ、暗号化アルゴリズムの最大バイト数は72であるように見えました。したがって、長いパスワードはとにかく72に切り捨てられるため、この数を72に制限するのが理にかなっているようです。
次に、Discordのパスワードを生成しましたが、最大長は128文字のようです。しかし、パスワードの最初の72文字で十分かどうかを確認するつもりです。はい、128文字のパスワードも最初の72文字に切り捨てられているので、Discordもbcryptを使用していると思います。
したがって、問題は次のとおりですパスワードの長さの制限を72文字に設定するか、ユーザーがより長いパスワードを選択できるようにすることをお勧めします（どのくらいの長さですか？128、256バイト？）切り捨てられましたか？
最初の基準はsecurityであり、それから初めて、ユーザビリティ、ストレージ、または実装の難易度が決まります。
サイレントトランケーションは、パスワード全体が受け入れられなかったときに受け入れられたとユーザーに誤解させるので、私は好みません。必要に応じて、システムで最大長を設定し、パスワード入力時にユーザーをその長さに制限することをお勧めします。 私が聞いた1つの悪いシナリオ は、以前の最大長を超えて文字の処理を開始し、突然長いパスワードのユーザーがログインできなくなるコード変更です。システムには、最初の72個のレコードしかありません文字とその長い文字列は、古いシステムの切り捨てがないと一致しません。それはイライラしたユーザーにつながります。
72文字で切り捨てる代わりに、SHA-256のような パスワードの事前ハッシュ を検討する必要があります。では、bcryptの計算による保護を提供しながら、72文字を超えるユーザーのパスワード文字列全体を考慮することができます。
私は通常、ばかげた制限に反対する人ですが、72文字を超えるパスワードを真剣に使用しているのは誰なのでしょうか。このように長いパスワードを入力するのは非常に実用的ではないため、ほぼ間違いなくロボット（またはパスワードマネージャのctrl + v）です。ロボット*とパスワードマネージャーは、パスフレーズではなくランダムな英数字の文字列を覚える必要があるかどうかを気にしません。
彼らが特殊文字を使用しないと仮定すると、1文字あたり26 + 26 + 10 = 62の可能性があり、最大72文字としましょう。これは_62^72 = 1.13*10^129_の可能性を可能にします。エントロピーのビット（はるかに扱いやすい数値）に変換すると、log(62^72)/log(2) = 428.7ビットのエントロピーが得られます。
最後にチェックしたところ、256ビットのキーは量子後でも妥当であると考えられているため、これはplentyである必要があります。
それがパスフレーズであるというまれなイベントでは、非常に標準的な辞書を取り上げましょう。私のDebianシステムのデフォルトの辞書です。いくつかの標準的な剪定（大文字と小文字を区別せず、 "horse"ではなく "horse's"のような所有格のバリアントを削除）した後、約5万語が含まれます。この数学についてはあまりわかりませんが、ランダムに選択した場合（パスフレーズを使用する場合）、各ワードが約log(50000)/log(2)=15.6ビットのエントロピーを与えることを意味すると思います。一般的に、平均単語長は5文字にスペースを加えたものと見なされるため、72は約12単語です。
これは、72文字のパスフレーズの_15.6*12 = 187.3_ビットのエントロピーに帰着します。私の口述にはすべての単語が含まれているわけではないため、下限として。私はあなたがいいと思います。
本当のばかげた制限はbcryptの72文字ですが、それを扱う必要がある場合は、ユーザーに設定するのが妥当な制限だと思います。
* OK、大丈夫、多分ロボットは気に入るでしょう。 Robot Rights Amendmentがあるときにもう一度質問してください。
編集：タイトルに答えていました。投稿でさらに質問に対処するには：
したがって、問題は、パスワードの長さの制限を72文字に設定するか、ユーザーが切り捨てられる場合でも、長いパスワードを選択できるようにする方がよいでしょうか[...]
黙って切り捨てないでください。これには利点はありません。 「105文字のパスワードは使用できない」というサポートリクエストを受け取るか、最終的に誰かが「OMGは、パスワードの最初の56％を入力するだけで、このがらくたが何であるか動作するようになります。 ？！？」後者は実際には妥当な点があり、前者は（たとえあったとしても）非常にまれになると思います。
最初の基準はセキュリティであり、それが初めてのユーザビリティ
クライアント側のTLS証明書について知りたいと思うかもしれません。