パスワードハッシュプレーンテキストの保存
私はパスワードのハッシュ/ソルティングについていくつかの調査を行ってきました。塩は秘密である必要はないと私は理解しています。しかし、秘密にする必要があるハッシュ自体については何も読んでいません。
実際のハッシュはどの程度曖昧にする必要がありますか？
次の単純なデータベーステーブルがあるとします。
ユーザー
-ユーザー名
- 塩
-ハッシュ
シナリオ
オンラインデータベースがあり、安全性が高い/非表示になっています。追加の暗号化などなしでソルトとハッシュを保存できます...しかし、このデータベースの特定のユーザーがローカルに保存されている場合はどうですかAndroidオフラインアクセス用のSQLiteデータベース。テーブルは同じように見えます、しかしソルトとハッシュはルート化されていないデバイスによってのみ保護されます（ https://stackoverflow.com/questions/3140230/sqlite-database-security ）。実際のSQLiteデータベースは簡単に読み取ることができます誰かが隠しファイルのコピーを作成した場合、このSQLiteデータベースにユーザーのソルト/ハッシュをそのまま保存しても安全ですか（ユーザーごとに異なるソルトがあります）？
ジョージは良い answer を持っていますが、これに関するいくつかの素晴らしい情報がありますが、これらすべてについて考慮する必要があることの1つは、ユーザーエクスペリエンスと攻撃シアターです。それが誰かの電話にある場合、そのデータを入手するのは誰でしょうか？
Local：そのデバイスに物理的にアクセスできる人。デバイスに物理的にアクセスすることで、メモリに読み込まれる暗号化の種類をメモリが監視するのを待ち、その方法でハッシュをプルできます。その場合、彼らはハッシュを持っています。これは、物理的なデバイスアクセスに関する問題の1つです。
リモートデータエクスプロイト：それらがすべて暗号化されている限り、ハッシュを含むファイルのコピー（おそらくDBダンプを介して）である場合ハッシュされたものに加えて、ハッシュを解読してそのハッシュからパスワードを取得しようとするまでには長い時間がかかります。
これを行うにはいくつかの方法があるはずです。心配している攻撃シナリオに最も適合するものを選択し、幸運なことにそれ（暗号化の秘密とハッシュ）を安全に保持してください。
私は、BCryptのような強力な（遅い）パスワードハッシュを十分に高い作業係数で使用していると想定します。汎用（高速）ハッシュを使用している場合、セキュリティ上の利点はごくわずかです。
ほとんどの場合、ハッシュは秘密にしておく必要があります。
- 将来、脆弱性が発見される可能性があります。
- ハッシュはパスワード強度の乗数です。パスワードが弱い場合、ハッシュ値が盗まれた直後に、結果のハッシュが簡単にクラックされます。
ただし、十分に調整されたパスワード強度の要件がある場合、パスワードをローカルに保存することが理にかなっている場合があります。
たとえば、GoogleのChromebookはこの手法を使用しており、ユーザーは同じパスワードを使用して、オンラインのGoogleアカウントとしてChromebookのロックを解除できます。
ただし、この目的で別のパスワードを使用する方が安全です。これにより、モバイルデバイスのパスワードが侵害された場合でもオンラインアカウントは安全であり、その逆も同様です。
Chromebooksの場合、Googleはセキュリティと利便性の比率がユーザーにとって許容範囲内であると判断したに違いありません。
ハッシュをモバイルに保存する場合は、Androidデバイスの場合、次に進む前に新しい質問を開始して、利用可能な最も安全な場所に保存するようにしてください。Androidには、利用可能な複数の保存場所とアプリのセキュリティ設定があります。
そして最も重要なのは、モバイルデバイスにできるだけ少ないハッシュを保存することです。できれば、デバイスの所有者のパスワードに対応する1つのハッシュのみを保存する必要があります。