8

私の質問は、このHow to hash long passwords (>72 characters) with blowfishから派生して います

パスワードをハッシュするために bcrypt(blowfish) を使用しています。したがって、この質問からわかったように https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length

文字数制限は 72 です。

それで、パスワードの最大長を制限することを考え始めましたが、これらの質問とその回答の後

https://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths

パスワードの長さを制限する理由

パスワードに最大長を課す必要がありますか?

言われていることはすべて反対です。のようなものに言及する

  • ストレージを保存
  • 古い Unix システムの経験
  • 長いパスワードをサポートしていないレガシー システムとの相互作用
  • 慣例（つまり、「私たちはいつもそのようにしてきた」）
  • 単純な無知または無知。
  • 平文で保存
  • また、a maximum length specified on a password field should be read as a SECURITY WARNINGこの回答による - https://stackoverflow.com/a/99724/932473
  • 等

したがって、私はこれらのケースのいずれとも一致しないと思います。もちろん、最大長が 10、さらに悪い場合は 8 または 6 などのばかげた制限には同意しますが、30、40、またはそれ以上の長さのパスワード (ソルト) は安全と見なされませんか? この記事から（少し古いですが）、

it can make only 71,000 guesses against Bcrypt per second

http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

そして、これは8文字のパスワード用です。したがって、レインボーテーブルのサイズが指数関数的に増加するにつれて、30文字以上のパスワードを1つだけブルートフォースするカスタムレインボーテーブルがどれほど巨大になるかを想像します(各パスワードには独自のソルトがあることを考慮して)。

同記事コメントより引用

パスワードに文字を追加するたびに、力ずくでクラックするのが指数関数的に難しくなります。たとえば、8 文字のパスワードには 95^8 の組み合わせのキースペースがあり、20 文字のパスワードには 95^20 の組み合わせのキースペースがあります。

したがって、それに応じて bcrypt を使用した 20 の長さのパスワードが必要になる場合は、95^20 / (71 000 * 3600 * 24 * 365) ~ 10 の 28 度年 (正しく実行した場合)

qsn1:さて、この場合、blowfish の場合、パスワードの最大長を 72 までに制限しないという意味があります。これ以降はすべてが切り捨てられるため、ここでは余分なセキュリティが得られないためです。

qsn2:ソルト (ユーザーごとに一意であり、db に保存されます) が存在する場合でも、やはりパスワードにコショウ (db に保存されるのではなく、アプリケーションにハードコーディングされます) を追加したいと考えています。少し余分なセキュリティが追加されるかどうかはわかっていますが、万が一の場合に備えて、db（またはdbバックアップ）がリークされているだけの場合は、pepperが役立つと考えています. https://security.stackexchange.com/a/3289/38200 したがって、たとえば 20 文字のペッパーを追加できるようにするには、パスワードの最大長を約 50 にする必要があります。次のように考えます。ユーザーが 70 文字を使用しているとしましょう。ほとんどの場合 (すべてではないにしても)、強力なフレーズを生成するのではなく、そのようなフレーズやスムスであるため、ユーザーを最大長で 50 に制限し、さらに 20 ～ 22 文字のペッパーを追加する方が安全ではないでしょうか。また、ハッカーが「一般的なフレーズ」のレインボー テーブルを使用しているとし72 character common phraseましょう50 character common phrase + 22 character random string。それで、このアプローチはコショウと50の最大長の方が良いですか、それとも私は間違っているので、72の最大制限を残す方が良いですか（qsn1が問題ない場合）？

ありがとう

ところで：

Owasp によると、パスワードの妥当な最大長は 160 https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Do_not_limit_the_character_set_and_set_long_max_lengths_for_credentials

Google のパスワードの最大長は 100 です

ここに画像の説明を入力

Wordpress の上限は 50 です

https://signup.wordpress.com/signup/

4

2 に答える 2

7

質問 1:パスワードの長さを制限する理由はまったくありません。BCrypt は、72 文字しか使用されていませんが、はるかに長いパスワードでも機能します。まったく利点はありませんが、理論的には、長いパスワードを使用するパスワード マネージャーを使用している人々を妨害することになります。将来別のアルゴリズムに切り替えた場合、制限はおそらく異なるため、72 文字で制限する理由はありません。

質問 2:ペラペラする代わりに、別のアプローチを使用することをお勧めします。パスワード ハッシュをサーバー側のキーで暗号化します。ペッパーを追加する理由は、攻撃者がサーバー上で特権を取得する必要があるためです。キーがないと、ハッシュの総当たり攻撃を開始できないためです (SQL インジェクションまたはデータベースの破棄されたバックアップは実行されません)。ハッシュを暗号化 (双方向) することで得られるのと同じ利点があります。

  1. この方法では、コショウ用に文字を予約する必要がなく、パスワードの 72 文字すべてを使用できます。
  2. ペッパーとは対照的に、サーバー側の鍵は必要なときにいつでも交換できます。コショウは実際にはパスワードの一部になり、次回のログインまで変更できません。
  3. 別の議論された点は、ペッパーが理論的にハッシュアルゴリズムを妨害する可能性があるということです.
于 2014-07-15T07:13:02.240 に答える
-3

ユーザーが提供するパスワードを単純にハッシュするだけでなく、bcrypt を使用して任意の長さの文字列全体を安全にハッシュしたい場合があります。さらに高いレベルのエントロピーのために、パスワードを bcrypt に渡す前にソルトしたい場合もあります。

文字制限を回避するために私が使用する 1 つのアルゴリズムは、中間ハッシュを使用することです。したがって、パスワードを直接ハッシュする代わりに、bcrypt の長さの制限内で短い文字列を生成し、bcrypt を使用してその中間文字列をハッシュする、より弱いハッシュ メカニズムを使用します。中間ハッシュは、bcrypt のように強力なハッシュである必要はありませんが、高度にランダム化された長いソルトを使用すると、このアプローチの効果を最大化できます。現在の中間ハッシュは sha512 です。

パスワードのハッシュに使用する手順は次のとおりです。

  1. /dev/urandom などのソースを使用して、暗号的に安全な長いソルトを生成します。(これはユーザーごとに行います。必要に応じて、アプリケーション全体のソルトを追加することもできます。) 将来パスワードの検証を行う予定がある場合は、このソルトを保存する必要があります。
  2. ソルトをユーザー提供のパスワードに連結します。
  3. 連結された値を sha512 にフィードし、結果をキャプチャします。これは、16 進数を表す 128 文字の文字列になります。
  4. エントロピーを追加して中間ソルト全体を利用するには、sha512 ハッシュ全体をループして 16 進数のペアを取得し、ペアの値を ASCII 文字に変換し、各文字を使用して 64 文字の長さの圧縮された中間ハッシュを作成します。 256 の可能な文字。
  5. 最終的に圧縮された中間ハッシュを、好みのパラメーター (コストなど) を使用して bcrypt にフィードし、結果のハッシュを取得します。
  6. これで、長いパスワードの値全体を利用する安全なハッシュが作成されました。
于 2018-01-19T20:23:31.883 に答える