ランダムに生成されたパスワードをハッシュする必要がありますか
ベストプラクティスは、ユーザーを保護するためにbcrpytなどのアルゴリズムを使用してユーザーパスワードをハッシュする必要があることですが、以下の条件を前提として、バックエンドでのハッシュは依然として重要ですか？
- パスワードは、十分なセキュリティ要素を備えたバックエンドによってランダムに生成されます
- ユーザーはそれを変更できません
パスワードはランダムに生成されるため、ユーザーはeバンキングなどの他のサービスで同じパスワードを使用しないため、パスワードをハッシュ化すると本当にセキュリティが向上しますか？
パスワードをハッシュすることのポイントは、攻撃者がパスワードファイルにアクセスできる場合（サーバーへの侵入、バックアップメディアの盗用、ホスティングプロバイダーのハッキングなど）、ハッシュからパスワードを回復できず、ユーザーとしてログインします。
2つのレベルがあります。
いくつかのハッシュ防御の2行目が必要です。これにより、サーバーに保存するもの（私は "-サーバー"と呼びます検証所定のパスワードで認証を行うシステム） ）は、実際にユーザーを偽装するには不十分です。これにより、部分的な読み取り専用の違反（盗まれたバックアップテープなど）が、より完全な読み取り/書き込みアクセスにエスカレーションされるのを回避できます。より長い議論については このブログ投稿 を参照してください。
パスワードをハッシュする場合、ソースパスワードのエントロピーが低い場合はmayパスワードハッシュ関数 を使用する必要があります。人間のユーザーが選択したパスワードは、エントロピーが低くなっています。パスワードを「ランダムに」生成すると、mayはエントロピーの高いパスワードを取得します。か否か。暗号的に安全なPRNGをフィードする既知の体系的なプロセスを通じてパスワードを生成することの良い点は、compute単にそれを推定するのではなく、エントロピー。ただし、それでも十分にそれを取得することを確認する必要があります。
たとえば、10個のランダムな文字（小文字と大文字、数字）のシーケンスとしてパスワードを生成し、すべての文字が互いに独立して均一に選択された場合、6210 可能なパスワードとそれらのそれぞれは、他のものと同じ確率で選択されます。エントロピーはlog（6210）（2を底とする対数）、つまり59.54ビット。それは悪くはありませんが、単純なハッシュ関数が使用されている場合、快適さには少し低すぎる可能性があります。良いGPUはbillions of MD5またはSHA-1 /秒で実行できるためです。次に、ソルトとイテレーションを追加する必要があります。つまり、bcryptを使用します（ただし、イテレーションの数は少なくてもかまいません）。
パスワードに少なくとも80ビットのエントロピーがある場合、それらは強力で決定的な攻撃者をも倒すのに十分強力であると考えることができ、単純なハッシュを使用できます（つまり、単純なハッシュ呼び出しで逃れることができますおよび塩を使用しない場合も）。ランダムな文字と数字で、これは14文字に変換されます。これが真実であると私は主張しますonly 14文字がランダムに、均一に、そして互いに独立して選択される場合。これらは、パスワードジェネレーターで満たすことができる要件ですが、ユーザーが選択したパスワードから現実的にそれらを期待することはできません。
他のパスワードと同じように扱う必要があります。
あなたがそれらを制御しない限り、ユーザーが他のシステムであなたのパスワードを再利用しないことを保証することはできません-私が私の新しいISPメールサーバーのパスワードを選択しなければならなかった例として、私は前のシステムから自動生成されたものを使用しました。私はそれを覚えています（計画よりもかなり長い一時的な期間）。
ユーザーにランダムに生成されたパスワードの使用を強制した場合でも、ユーザーはそれを他の目的で使用する可能性が中程度です。かなりの数がそれを書き留めるか、プレーンテキストでどこかに保存するため、そのリストを短くしておく方が簡単です。ユーザーがパスワードのセキュリティについて半分の手がかりしか持っていないと仮定することはできません。また、適切なセキュリティに煩わされるほどサービスを評価しないユーザーもいます。
簡単な答えはイエスです。
繰り返し発生することがあるのは、ユーザーがdbのパスワードセクションにアクセスできる場合、db全体にアクセスできるということです。これは、データを保護する場合には適切な仮定ですが、パスワードをハッシュしないことを正当化しようとする場合には適切ではありません。理論的には同じロジックが、ユーザーがパスワードを変更できる通常の使用例に適用できます。
一般的なパスワード（計算だけではない）は、ユーザー側の既知の変数に対する検証の形式です。パスワードをプレーンテキストで保存すると、内部セキュリティリークが発生し、理由もなく信頼が低下します。
これについて考えてみてください。パスワードに同じ要件があったとしても、パスワードをハッシュしないサイトに個人情報を信頼しますか？
与えられたシナリオでは、攻撃者がパスワードストアへの読み取りアクセスを取得したが、書き込みアクセスや他のデータへのアクセスを取得しなかった場合、ハッシュされたパスワードを使用するとあなたを保護します。その場合、パスワードを使用してログインし、より多くのデータにアクセスできます。
攻撃者がパスワードストアへの書き込みアクセス権を取得すると、ハッシュを自分のパスワードのハッシュに置き換えることができるため、その場合、ハッシュによって保護されることはありません。
また、パスワードデータベースが危険にさらされている場合、サーバー上の他のデータも危険にさらされていると想定できるため、攻撃者がログインする理由さえない場合もあります。
あなたがする必要はないと思います。あなたがそれを探す必要があるのはこれだけです：データベースが危険にさらされている場合、ハッカーは非常に高速に任意のアカウントにログインし、ユーザーが許可しているアクションを実行できます。このシステムが他のサービスにリンクされていると、混乱が非常に速くなる可能性があります。それはあなたの呼び出しです、私は個人的にはしませんが、ユーザーがプログラムを通じてアクセスできる他のサービスに応じて検討します。