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

https://stackoverflow.com/questions/98768

01-07-2019
|

質問

パスワードに最小限の長さを課すことが（ユーザーを自分自身から守るために）非常に理にかなっていることは理解できますが、私の銀行パスワードの長さは 6 ～ 8 文字であるという要件があるのですが、疑問に思い始めました...

これではブルートフォース攻撃が容易になるだけではないでしょうか?（悪い）
これは、私のパスワードが暗号化されずに保存されていることを意味しますか?（悪い）

(できれば) 優れた IT セキュリティ専門家が働いている人がパスワードの最大長を課している場合、私も同様のことを検討すべきでしょうか?これの長所/短所は何ですか?

解決

パスワードは、長さに関係なく、32、40、128 にハッシュされます。最小限の長さを設定する唯一の理由は、パスワードが簡単に推測されないようにするためです。最大長には意味がありません。

義務的な XKCD 最大長を課すとユーザーに不利益をもたらす理由を説明します。

他のヒント

パスワードフィールドに指定された最大長は、次のように読み取られる必要があります。 セキュリティ警告:賢明でセキュリティ意識の高いユーザーは、最悪の事態を想定し、このサイトが文字通りあなたのパスワードを保存していることを期待する必要があります（つまり、epochwolf が説明したように、ハッシュされていません)。

その場合は次のようになります。（a）可能であればペストのようなこのサイトの使用を避けます[彼らは明らかにセキュリティについてナットを知っています]（b）サイトを使用する必要がある場合は、他の場所で使用するパスワードとは異なり、パスワードが一意であることを確認してください。

パスワードを受け入れるサイトを開発している場合は、同じ目に遭いたくない限り、愚かなパスワード制限を設定しないでください。

[もちろん、コードは内部的に、巨大なパスワードの解読を避けるために、最初の 256/1028/2k/4k (何でも) バイトだけを「重要」として扱うことができます。]

信頼できないソースからのパスワードを受け入れる場合、完全に無制限のパスワード長を許可すると、大きな欠点が 1 つあります。

送信者は、他の人へのサービス拒否につながるような長いパスワードを提供しようとする可能性があります。たとえば、パスワードが 1 GB のデータであり、メモリが不足するまでパスワードを受け入れることに時間を費やしたとします。ここで、この人物が、あなたが受け入れてもよい回数だけこのパスワードを送信してきたとします。関連する他のパラメータに注意しないと、DoS 攻撃につながる可能性があります。

上限を 256 文字などに設定するのは、今日の標準からすると寛大すぎるように思えます。

まず、銀行に優秀な IT セキュリティ専門家がいるとは考えないでください。そうでない人もたくさんいます.

とはいえ、パスワードの最大長には意味がありません。多くの場合、ユーザーは新しいパスワードを作成する必要があり (すべてのサイトで異なるパスワードを使用する価値についての議論はさておき)、ユーザーがパスワードを書き留めるだけになる可能性が高くなります。また、ブルートフォースからソーシャルエンジニアリングまで、あらゆる手段による攻撃に対する脆弱性も大幅に高まります。

パスワードの最大長制限は、OWASP 認証チートシートによって推奨されなくなりました

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

段落全体を引用すると、

パスワードが長いほど、文字の組み合わせが多くなり、攻撃者による推測がより困難になります。

パスワードの最小長はアプリケーションによって強制される必要があります。10 文字未満のパスワードは弱いとみなされます ([1])。最小長の強制により、一部のユーザーがパスワードを覚えるのに問題が生じる可能性がありますが、アプリケーションは、一般的なパスワードよりもはるかに長くてもはるかに覚えやすいパスフレーズ (文または単語の組み合わせ) を設定することをユーザーに奨励する必要があります。

パスワードの最大長を低く設定しすぎると、ユーザーがパスフレーズを作成できなくなります。通常の最大長は 128 文字です。20 文字未満のパスフレーズは、小文字のラテン文字のみで構成されている場合、通常は弱いと見なされます。どの文字も重要です!!

ユーザーが入力したすべての文字が実際にパスワードに含まれていることを確認してください。ユーザーが指定した長さよりも短いパスワードを切り詰めるシステムが確認されています (たとえば、20 文字を入力したときに 15 文字で切り詰められるなど)。これは通常、すべてのパスワード入力フィールドの長さをパスワードの最大長とまったく同じ長さに設定することで処理されます。これは、パスワードの最大長が 20 ～ 30 文字のように短い場合に特に重要です。

パスワードの最大長を強制する理由の 1 つは、フロントエンドが多くのレガシーシステムバックエンドと接続する必要があり、そのうちの 1 つ自体がパスワードの最大長を強制する場合であると考えられます。

別の思考プロセスは、ユーザーが短いパスワードを使用することを強制された場合、(友人や家族によって) 簡単に推測されるキャッチフレーズやニックネームよりも、ランダムな意味不明な言葉をでっち上げる可能性が高いということかもしれません。もちろん、このアプローチは、フロントエンドが数字と文字の混合を強制し、l33t-speak で書かれた単語を含む辞書の単語を含むパスワードを拒否する場合にのみ有効です。

パスワードの最大長を課す正当な理由の 1 つは、パスワードのハッシュ化プロセス (bcrypt などの遅いハッシュ関数の使用による) に時間がかかりすぎることです。サーバーに対して DOS 攻撃を実行するために悪用される可能性のあるもの。

繰り返しになりますが、時間がかかりすぎるリクエストハンドラーを自動的に削除するようにサーバーを構成する必要があります。したがって、これが大きな問題になるとは思えません。

どちらの箇条書きも非常に正しいと思います。パスワードをハッシュ化して保存している場合、パスワードの長さは DB スキーマにまったく影響しません。パスワードの長さに制限がない場合、ブルートフォース攻撃者が考慮しなければならない変数が 1 つ増えます。

パスワードの長さを制限する言い訳は、設計が悪いという以外に見当たりません。

パスワードを最大長にすることで得られる唯一の利点は、長すぎるパスワードによって引き起こされるバッファオーバーフロー攻撃のリスクを排除することですが、その状況に対処するより良い方法があります。

ストレージは安いのに、なぜパスワードの長さを制限する必要があるのでしょうか。パスワードを単にハッシュするのではなく暗号化する場合でも、64 文字の文字列を暗号化するのにかかる時間は 6 文字の文字列よりもはるかに長くはなりません。

おそらく、銀行システムは古いシステムをオーバーレイしているため、パスワード用に一定量のスペースしか許可できなかったのでしょう。

私の銀行もこれをやっています。以前はあらゆるパスワードを許可していましたが、私は 20 文字のパスワードを使用していました。ある日、変更したところ、なんと最大値が 8 文字になり、古いパスワードに含まれていた英数字以外の文字が削除されていました。私には意味が分かりませんでした。

私が英数字以外の 20 文字のパスワードを使用していたときも、銀行のバックエンドシステムはすべて正常に動作していたので、レガシーサポートが原因であるはずはありません。たとえそうであったとしても、任意のパスワードを使用して、レガシーシステムの要件に適合するハッシュを作成できるようにする必要があります。さらに良いことに、レガシーシステムを修正する必要があります。

スマートカードソリューションは私には合いません。このままではカードが多すぎるので…別のギミックは要りません。

任意のサイズのパスワードを受け入れる場合は、ハッシュ化される前に、パフォーマンス上の理由からパスワードがカーテンの長さに切り詰められると想定されます。切り捨てに関する問題は、時間の経過とともにサーバーのパフォーマンスが向上するにつれて、ハッシュが明らかに異なるため、切り捨ての前の長さを簡単に増やすことができないことです。もちろん、両方の長さをハッシュしてチェックする移行期間を設けることもできますが、その場合はより多くのリソースが使用されます。

長いパスワードを検証しないようにと言っている人は無視してください。Owasp は文字通り、128 文字で十分であると言っています。十分な呼吸スペースを与えるために、必要に応じて、たとえば 300、250、500 などのもう少し多くの息を与えることができます。

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

パスワードの長さ長いパスワードは、文字のより大きな組み合わせを提供し、その結果、攻撃者が推測することをより困難にします。

...

ユーザーがパスフレーズを作成できないため、最大パスワードの長さを低く設定してはなりません。 一般的な最大長は128文字です. 。20文字より短いパスフレーズは、通常、小文字のラテン文字だけで構成されている場合、弱いと見なされます。

最大長は必要ですか?これは、IT 分野では興味深いトピックです。一般的に、パスワードが長くなると覚えにくくなり、したがって書き留められる可能性が高くなります (明らかな理由から、絶対に禁止です)。また、パスワードが長くなると忘れられやすくなる傾向があり、必ずしもセキュリティ上のリスクがあるわけではありませんが、管理上の手間や生産性の低下などにつながる可能性があります。これらの問題が差し迫ったものであると考える管理者は、パスワードに最大長を課す可能性があります。

私は個人的に、この特定の問題についてはユーザーごとに異なると考えています。40 文字のパスワードを覚えられると思うなら、なおさらです。

ただし、パスワードは急速に時代遅れのセキュリティモードになりつつあり、スマートカードと証明書認証は、あなたが問題だと述べたように、総当たり攻撃が非常に困難または不可能であることが証明されており、公開キーのみを秘密キーとともにサーバー側に保存する必要があります。常にカード/コンピュータのキーを押してください。

長いパスワードまたはパスフレーズは、長さだけで解読するのが難しく、複雑なパスワードを要求するよりも覚えやすいです。

おそらく、最小長をかなり長い (10 以上) にして、無駄な長さを制限するのが最善です。

レガシーシステム (前述) または外部ベンダーのシステムとのインターフェースでは、8 文字の上限が必要になる場合があります。また、ユーザーを自分自身から救おうとする誤った試みである可能性もあります。この方法で制限すると、pssw0rd1、pssw0rd2 などが多くなりすぎます。システム内のパスワード。

パスワードがハッシュ化されない理由の 1 つは、使用されている認証アルゴリズムです。たとえば、いくつかのダイジェストアルゴリズム認証メカニズムでは、クライアントとサーバーの両方が入力されたパスワードに対して同じ計算を実行する必要があるため、サーバーでパスワードの平文バージョンが必要です (通常、パスワードはランダムに生成されたパスワードと結合されるため、毎回同じ出力は生成されません) 「nonce」、2 つのマシン間で共有されます）。

場合によってはダイジェストの一部を計算できるため、これを強化できますが、常にそうとは限りません。より良い方法は、パスワードを元に戻せる暗号化で保存することです。これは、暗号化キーが含まれるアプリケーションソースを保護する必要があることを意味します。

Digst auth は、暗号化されていないチャネルでの認証を可能にするためにあります。SSL またはその他のフルチャネル暗号化を使用している場合は、ダイジェスト認証メカニズムを使用する必要はありません。つまり、パスワードは (安全な値が与えられた場合に) ネットワーク上で平文で安全に送信できるため、代わりにパスワードをハッシュして保存できます。

必要な場合を除き、制限を課さないようにしてください。注意してください:さまざまなケースで必要になる可能性があり、今後も必要になるでしょう。レガシーシステムへの対応もその理由の 1 つです。非常に長いパスワードの大文字と小文字をよくテストしてください (システムは 10MB の長さのパスワードを処理できますか?)。使用するキー定義機能 (KDF) (通常は PBKDF2、bcrypt、scrypt) には多くの時間とリソースがかかるため、サービス拒否 (DoS) 問題が発生する可能性があります。実際の例: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

わずか 8 文字の長さのパスワードは単純に間違っているように思えます。制限がある場合は、少なくとも 20 文字にすることをお勧めします。

適用すべき唯一の制限は 2000 文字制限、またはその他の非常に高い制限のようなものだと思いますが、それが問題になる場合はデータベースサイズを制限するだけです。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow