問題タブ [password-storage]

私の質問は、この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、またはそれ以上の長さのパスワード (ソルト) は安全と見なされませんか? この記事から（少し古いですが）、

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/

パスワードをリセットするとき、新しいパスワードは古いパスワードとは異なる必要があるという要件があります。これを、複数の Password オブジェクトを持つ User オブジェクトと、userId、password、および createdDate を含む Password オブジェクトとして設計することを考えています。

パスワードがリセットされると、ユーザーのすべての古いパスワード (最新のパスワードを除く) に対して新しいパスワードがチェックされ、一致が見つかった場合は破棄されます。

古いパスワードのリストにまだない場合は、ユーザーのパスワード リストに新しいエントリが作成されます。ユーザーがログインすると、システムは createdDate に基づいて最新のパスワードを確認する必要があります。

このデザインに関するあなたの考えを確認し、これを行うためのより良い方法があるかどうかを確認したかっただけです. ありがとう。

これまでのところ、bcrypt には問題はありませんでした。何らかの理由で、次のパスワードが機能しません。UIO78349%^&(]\\';=パスワードが機能しないのはこれが初めてです。誰かが説明してくれることを願っています。私はネットを探して文字制限について読みましたが、これはそれをはるかに下回っています. 違いがあるかどうかはわかりませんが、パスワードのユーザー入力は mysqli_real_escape_string を経由しています。

ログインフォームが配置されているコードの最初のバッチ:

ここで js.

呼び出されるphpは次のとおりです。

これまでのところ、投稿の上部にあるパスワードまで、パスワードの問題はありませんか? あなたが私に尋ねると奇妙です。

サインアップ フォームを通じて新規ユーザーを受け入れるか、Facebook を使用してログインするアプリケーションを設計しています。

ユーザーがサインアップすると、ユーザー レコードを作成し、暗号化されたパスワード (ハッシュ) をUSERテーブルに格納します。ユーザーが FB からサインアップした場合でも、ユーザー レコードを作成したいと考えています。

しかし、私は彼らの FB パスワードにさらされないので、パスワード列をどのように処理すればよいでしょうか。または、ユーザー ID/ログイン/パスワードをテーブルからUSER分離して、別のテーブルに保持する必要があります。FB ユーザーは、この新しいテーブルにレコードを持ちません。

私の.bashrcファイルには、リモート Web サイトでバックアップ コマンドを発行するために使用される関数がいくつかあります。現在、ユーザー名とパスワードのフィールドは、関数定義内のプレーン テキストで関数ローカル文字列として格納されています。これを行うより良い方法はありますか？

これまでの私の考えは、自分のユーザー アカウントだけが読み取りアクセス権を持つファイルにパスワードのハッシュ バージョンを配置し、そのファイルに対してハッシュ解除コマンド ライン関数を実行し、平文の結果をメモリに保存して使用することでした。それをクリアします。

これを達成するためのより良い/安全な、または事実上の一般的な方法はありますか?

ありがとうございました。