私たちのサイトによってランダムに生成されたハッシュパスワードを遅くする理由は何ですか？
私が管理しているサイトは、3年間運用されています。登録すると、サイトは大きな（20桁の）ランダムな16進パスワードを生成します。 MD5ハッシュ化して無塩で保存します。
MD5はパスワードに悪いことをリード開発者に言ったとき、悪者がそれを取得した場合、パスワードはランダムであるため、解読することはできません。そして、悪者がそれをクラックしたとしても、ユーザーがそれを他のサイトで再利用できないように生成します。
ベストプラクティスを使用する必要があることをどのように彼に納得させることができますか？彼はとても頑固です...
サイトは、登録時にユーザーごとにランダムなパスワードを生成します。重要な問題は、ユーザーが後で自分のパスワードを手動で設定できるかどうか、またはサイトが生成したランダムなパスワードの使用を強制されるかどうかです。 2つのケースを個別に見てみましょう。
ランダムなパスワード
私の知る限り、これはあなたが質問で説明しているシナリオです。 残念ながら、あなたの開発者は（ほとんど）正しいです。少なくとも、ハッシュの1回の反復と大きな低速ハッシュの比較。あなたの質問には、「ベストプラクティス」が何のために意図されているのかを考慮せずに、盲目的に適用するという風味があります。これの見事な例のために、これは良い読み物です：
これらの迷惑なパスワードルールを発明した人は、今あなたの時間を浪費していることを後悔しています
提案
MD5からSHA256に切り替えて、おそらくユーザーごとのソルトを追加し、32文字のパスワードに移行することを検討してください。ただし、大きな低速ハッシュ関数を追加すると、サーバーの負荷が増加し、セキュリティがほとんどまたはまったく追加されません（少なくとも、実装内の他の誤解を排除できます）。
ブルートフォース緩和としてのハッシュの理解
データベースを盗んだブルートフォース攻撃者がパスワードハッシュを解読するために行う必要がある作業の量は、おおよそ次のとおりです。
entropy_of_password * number_of_hash_iterations * slowness_of_hash_function
ここで、entropy_of_passwordは、パスワードの可能性の数、つまり「推測可能性」です。この「式」が128ビットのエントロピー（または同等の作業係数/実行するハッシュ命令の数）よりも大きい限り、問題はありません。ユーザーが選択したパスワードの場合、entropy_of_passwordは非常に低いため、非常に遅いハッシュ関数（PBKDF2またはscryptなど）を何度も繰り返す必要があります（100,000など）。仕事の要因。
「20桁の16進数」では、16桁あると思います。20 = 280 「ベストプラクティス」よりも低い可能なパスワード2128、しかしあなたが政府や銀行でない限り、あなたはおそらくパスワードだけのエントロピーから十分な総当たりのセキュリティを持っています。
すべてのハッシュの事前計算が2のようなものであるため、ソルトもここでは意味がありません。80 * 32ビット/ハッシュ、これはおよそ1 ZB（または 5000 x惑星上のすべてのハードドライブの容量を合わせたもの ）。レインボーテーブルはこれを少し支援しますが、率直に言って、それを実行できる攻撃者なら誰でも私たち全員を攻撃するに値します。
攻撃者が平文を無料で持ち去ることを防ぐためにパスワードをハッシュしたいのですが、1回のハッシュで十分です。ただし、MD5からSHA256に切り替えて、32文字のパスワードに変更することを検討してください。
人間の脳のパスワード
このスレッドのコメンターは、サイトがパスワードを生成するというあなたの声明にもかかわらず、ユーザーは実際に自分のパスワードを選択できるという考えに夢中になっているようです。
ユーザーがパスワードを変更する可能性があるとすぐに、単一のハッシュ反復は、現在の低エントロピーパスワードを保存するためのオプションではありません。この場合、パスワードの保存に関してすべてのベストプラクティスを実行する必要があることは間違いありません。
塩漬け
どちらの方法でも（ユーザーが選択したパスワードまたはランダムなパスワード）、おそらくユーザーごとのソルトが必要です。
ユーザーが選択した場合、塩はベストプラクティスの一部です。 '言っ途切れる。
ランダムな場合、@ GordonDavissonはコメントで本当に素晴らしい攻撃を指摘しています [1] 、 [2] ハッシュ計算と比較して、dbルックアップは基本的に無料であるという観察に基づいています。ハッシュを計算してすべてのユーザーのハッシュと比較することは、本質的に特定のユーザーのハッシュと比較することと同じコストです。 anyアカウント（specificアカウントを解読しようとするのではなく）に満足している限り、システムのユーザー数が多いほど、攻撃の効率が高くなります。
たとえば、100万のアカウントを持つシステムの無塩ハッシュ化パスワードdbを盗んだとします（約220）。 2で20 アカウント、あなたは統計的に最初の2でヒットを得ると期待しています60 推測。あなたはまだO（280）guesses、ただしO（260）ハッシュ* O（220）dbルックアップ〜= O（260）ハッシュ。
ユーザーごとのソルトは1人のユーザーを攻撃するコストですべてのユーザーを攻撃するを防ぐ唯一の方法です。
補足 Mike Ounsworth の答え、彼らの乱数が適切に生成されていれば、あなたの開発者はおそらく正しいでしょう。
PRNGがこれらのパスワードをひどく生成する場合、攻撃者は、PRNGの状態を推測して将来のパスワードを予測することができます。たとえば、セッション間で更新されない内部状態でメルセンヌツイスターを使用する病理学的なケースでは、次の攻撃が実行可能です。
- 多数のアカウントを順番にリクエストする
- PRNG=から対応する大量のバイトを生成し、それらすべてを私に送信します
- 私はこれらのバイトを使用して PRNGの内部状態を推測する パスワードを生成したとき
- これから、PRNGが後続のすべてのユーザーのパスワードを生成したときの内部状態を推測します。PRNGが生成する将来のすべてのパスワードは、さらに、MTを逆方向に実行して、既知の時点から以前のすべての出力を生成できます。
- データベースにアクセスせずに、システムで使用中のすべてのパスワードを計算しました
暗号化された安全な乱数発生源を使用してください。あなたの言語の組み込みPRNGはそうではないかもしれません。
また、ユーザーは実際にこれらのパスワードをどのように覚えていますか？長く予測できないものを生成すると、ユーザーはpassword.txtデスクトップ上。パスワードが設定ファイルのどこかに隠されている場合、おそらく本当の問題はありませんが、ユーザーの頭にあるはずの何かである場合、ユーザーの機能を大幅に過大評価している可能性が高く、彼らに彼ら自身のセキュリティ欠陥を発明させる。
他の人が言ったように、80ビットの乱数のMD5を逆にすることは難しい問題です。そのため、誰かがハッシュのテーブルを入手した場合、おそらくユーザーアカウントにアクセスできません。
ただし、ユーザーがそれらの80ビットの乱数をどこに格納するかを検討することもできます。それはおそらく彼らの頭の中になることはありません。最良のケースは、かなり安全なキーチェーンまたはパスワードリポジトリアプリです。最悪の場合、ホームディレクトリにPASSWORDS_FOR_YER_APP.TXTを含むファイルが作成されます。