強力なアルゴリズムで弱いハッシュを再ハッシュすると、強力になりますか？
次の状況を想像してみてください。私たちは本当に安全なはずのウェブアプリケーションを作っています
現在、アカウント/ユーザーは直接追加されていませんが、ログインコードが記載された手紙を受け取ります。時々、このログインコードの無塩SHA-1ハッシュとその他の本当に基本的な情報を含むファイルを取得します。
SHA-1が責任として見なされている日であり、これらのハッシュを生成するソフトウェアが私たちの管理下にないことを考慮する（それはおそらく、より良いハッシュを実行できない古いソフトウェアでもある）
Bcryptを使用して受信したハッシュをハッシュするソリューションになりますか？これは、私が正しい場合、安全ではない/速すぎるという問題を解決するはずですか？コショウも追加する必要がありますか？
私が見逃したかもしれない他の問題はありますか？それとも、問題をプッシュバックして、ハッシュ関数を改善するためにソフトウェアを修正してもらう必要がありますか？
明確化：
企業の従業員であり、このプロジェクトの承認が必要です。
サードパーティは、クライアント企業の顧客に関する機密情報を処理するクライアント企業向けのシステムを作成しました。彼らは顧客の一部に私たちのアプリケーションにログインする能力を与えたいと思っています。これは私たちの顧客の従業員が知っていることであり、彼らが私たちのアプリケーションにユーザーを手動で追加しなければならないなら私たちのクライアントは承認を得られないので、これは彼らのシステムを通して行われなければなりません。 。
また、漏洩や違反があった場合（技術的には機密情報へのアクセス権はありませんが、独自のアプリケーションであっても、ユーザーに関する名前や識別情報がない場合）は、両方に害を及ぼす望ましくない否定的な注意を引き付ける可能性があります。クライアントと私たち。
問題は、サードパーティが作成したシステムが無塩SHA-1ハッシュしか実行できないことです。だから私の質問は、これを回避できるかどうか試してみることです。あるいは、クライアントに、より良いハッシュシステムを実装するようにサードパーティに強制するように強いる場合、彼らは答えたくないだけで答えを言うかもしれません。またはそれは多くのお金がかかるかもしれません。
まだ漠然としていて、少し良く説明できたらいいのですが。 :)
はい、bcryptで再度ハッシュ化することをお勧めします。ただし、ログインコードのエントロピーが増えるわけではなく、クラックに時間がかかるようになることに注意してください。ですから、そもそもエントロピーが本当に低い場合、クラックを実行不可能にするために非常に高いコスト要素が必要になる可能性があります。
余談ですが、 この質問 の回答で説明されているように、一般的には、1つの優れたハッシュ関数でハッシュする方が、多くの関数をいじるよりも優れています。しかし、あなたにはそのオプションがないので、そこでの議論はあなたのケースにとって本当に有効ではありません。
コショウの使用については、代わりにハッシュを暗号化することをお勧めします。同じ種類の保護を提供しますが、より高い柔軟性を提供します。しかし、塩漬けの代わりにはなりません。
This と this はあなたにとって興味深い読書かもしれません。また、 Roshan Bhumbra には、最初のログイン後の1つの関数のみでの再ハッシュについて 興味深い提案 があります。
転送中の暗号化
現在のシステムでは、事実上のパスワードは「このログインコードのSHA-1ハッシュ」のようですが、有効なファイルを作成するには一致するハッシュを保持するだけで十分ですが、攻撃者が何かを直接悪用できるかどうかは不明です。ただし、この点では、プレーンテキストのパスワードを送信するよりも安全です。これは、安全で暗号化されたチャネル、つまり適切なhttps/sftp /などを介して「ファイルを取得」する限り適切です。
ストレージでの暗号化
このシステムのリスクは、攻撃者がそのファイルのコピーを入手できる場合、ユーザーの完全なパスワードを入手できることです。 [〜＃〜] if [〜＃〜]これらのハッシュを保存する必要がある場合、保存のためにbcryptでハッシュすることが合理的であり、主な問題はあなたが必要とすることです受信したSHA-1ハッシュをすぐに削除し、そのコピー（一時ファイル、バックアップ、キャッシュなど）がストレージに残っていないことを確認してください。
言及されていないように見える別のオプションが表示されますが、ハッシュを生成するシステムがBcryptを使用できる場合は、この方法がより効果的です。
ユーザーがログインするときにハッシュを更新する必要があるだけです。これは、同時に2つの異なるハッシュアルゴリズムを使用することを意味しますが、1つの値で2つのアルゴリズムを使用することに関して@Andersによって言及された「問題」を回避します。
ハッシュの横に値を格納して、それがどのタイプかをアプリケーションに伝えることができます。それがSHA-1ハッシュの場合は、入力したパスワードをハッシュして（正しい場合）、それを格納できます。
元のハッシュがソルト化されていない場合は、ソルト化されたハッシュアルゴリズムを、受け取った元のソルト化されていないハッシュに単純に適用できます。
ただし、これらのハッシュが結合されたハッシュアルゴリズムを使用していることがデータベースで明確にマークされていることが重要です。後で別のハッシュアルゴリズムで保護されたデータベース内の別のユーザーが存在する可能性はまったくありません。その時点で、データベース内の各ユーザーに使用する正しい関数を知っていることが重要です。
次回ユーザーがログインしたときに、データベースに保存されているハッシュをアップグレードすることは可能です。ただし、bcryptは、SHA1に続くbcryptよりもわずかに安全であるため、重要ではない場合があります。
元のハッシュがソルト化されている場合は、よりトリッキーになります。その場合でも2層のハッシュを適用できますが、その場合はすべてのソルトと最後のハッシュ値のみを保存することが非常に重要です。