web-dev-qa-db-ja.com

パスワードの実装を切り替えるときに、既存のSHA1ハッシュでbcryptを使用しても十分ですか？

パスワードを保存する現在の実装がsha1(password)であるCMSの改善に取り組んでいます。私は上司にそのようにすることは信じられないほど安全ではないことを説明し、私たちはbcryptに切り替えるべきだと彼に言いました、そして彼は同意しました。

私の計画は、bcryptを介してすべての既存のハッシュを実行し、それらをパスワードフィールドに格納し、次のpsudoコードを使用してパスワードをチェックすることでした：correctPassword = bcrypt_verify(password, storedHash) or bcrypt_verify(sha1(password), storedHash)。

この方法では、新しいユーザー、またはパスワードを変更するユーザーは「実際の」bcryptハッシュを取得しますが、既存のユーザーはすべてパスワードを変更する必要はありません。これを行うことの不利な点はありますか？すべてのユーザーに新しいパスワードを選択するよう依頼することはおそらく理想的ですが、これを行うことでセキュリティの面で多くのことを失うのでしょうか？

攻撃者がデータベースとコードの両方にアクセスできたとしても、bcryptへの「入力」の大部分が40文字の16進数文字列であっても、遅い部分（bcrypt_verify()）は、各ユーザーでパスワードを試行するたびに呼び出す必要があります。

passwordspassword-managementshabcrypt
55
Alex

実際、これは、そうでなければ安全に保存されていないパスワードを保護するための良い方法です。ただし、この方式には1つの弱点があります。これは、古いハッシュをマークすることで簡単に克服できるため、この解決策をお勧めします。

_if (checkIfDoubleHash(storedHash))
  correctPassword = bcrypt_verify(sha1(password), storedHash)
else
  correctPassword = bcrypt_verify(password, storedHash)
_

攻撃者が古いバックアップを手に入れているところを想像してみてください。 SHAハッシュが表示され、bcrypt_verify(...) or bcrypt_verify(sha1(...))でテストすると、ハッシュをパスワードとして直接使用できます。

ほとんどのbcryptライブラリは、使用するアルゴリズム自体のマークを追加するため、独自の「ダブルハッシュマーク」を追加しても問題ありませんが、もちろん、このために別のデータベースフィールドを使用することもできます。

_$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
 |
 hash-algorithm = 2y = BCrypt
_
77
martinstoeckli

新旧両方のすべてのパスワードに単にbcrypt（sha1（password））を使用しないのはなぜですか？これは、古いハッシュをパスワードとして使用する人々の問題を回避し、提案よりも簡単です。

8
Peter Green

これは良い戦略です。ユーザーが160ビットより長い完全にランダムなパスワードを生成することを決定しない限り、セキュリティが失われることはありません。したがって、違いはごくわずかです。 （その場合でも、元のテキストを総当たりにするのにかなりの時間がかかります）

ユーザーが次にパスワードを変更したときにパスワードを移行するロジックを実装することもできますが、ハッシュがリークしていると思わない限り、パスワードをすぐに変更する必要があるリスクはありません。

4
Lucas Kauffman

私は最近、パスワードをbcryptに移行するための同様のシステムを実装しました。ただし、SHA1の代わりに、元々はSHA256（password + salt）ハッシュを使用していました。

ユーザーがログインするときにユーザーをbcryptに切り替えると（オプション）、またはパスワードを変更すると、このソルトが再生成されます。したがって、ハッシュは元のハッシュに基づいていません。次に、このノンスをIVとして主に使用し、データベースのbcryptハッシュをデータベースの外部に格納されているキーで暗号化します。

これを行うことは、インジェクション攻撃と、有用なパスワード情報を提供するデータベースのみから引き出されたデータを本当に防ぐだけです。ただし、オーバーヘッドは問題ではなく、必要に応じていつでもこの外部キーを変更できます。

Bcryptへの入力としてSHA256ハッシュを使用すると、入力パスワードの長さをbcryptの最大長未満に保つこともできます（ 関連記事 ）

この方法でSHA1を使用することで参照も見たときの唯一の懸念は、2つのリンクの2番目にあるThomas Porninからのアドバイスと問題を探していたときでした。

安全なハッシュ関数を使用してパスワードを前処理することは安全です。 bcrypt（SHA-256（password））が壊れている場合は、パスワードが推測されたか、SHA-256のセキュリティ特性の一部が偽であることが証明されていることがわかります。そのレベルで塩をいじる必要はありません。パスワードをハッシュ化してから、結果に対してbcryptを使用します（bcryptマンデートとして、saltを使用）。 SHA-256は安全なハッシュ関数と見なされます。

したがって、SHA1を保持することが適切な選択ではない可能性があります-そもそもなぜそれを最初の場所でのみ使用することから移行するのか。とはいえ、近い将来、bcrypt（SHA1（password））を攻撃する際に実用的な価値を提供し、bcrypt自体との何らかの妥協を必要としない種類の攻撃が存在する可能性は低いと言われています。

2
John Pettit