ソルトHMACを使用しているが、たとえばPBKDF2、scryptを使用していない、主要な業界パスワードリーク
新しいシステムのパスワードストレージを保護するために、プロジェクトの上級者に繰り返し強化機能を使用するように説得しようとしています。現在の提案では、saltされたSHA-256のHMACのようなものが格納されます（おそらく、その他のHMAC入力は、ボーナスセキュリティのために個別に格納されています）。
セキュリティ開発者は異なる言語を話すので、基本的に直接開発者と通信したり、要件を正確に決定したりすることは不可能です。私はビジネスケーススタディしか理解していないように見える上級者に直行しました。私は抗議の中で、基本的にそれらを説得する唯一の方法は、saltとHMACの両方を使用し、反復的な強化ではなく、結果として多くのパスワードが危険にさらされた主要なパスワードリークの実際の例を見つけることであろうと言われました。
私が不可能を達成しようとするつもりはなく、彼らにパスワード保存のための正確な標準的な推奨事項を実装させるつもりはないことを理解してください。繰り返し強化を検討してもらいたいだけです。
SaltとHMACが使用された顕著な実例はありますか？しかし、反復強化の欠如により、とにかく多くのパスワードが侵害されましたか？ Facebook、LinkedInなどの有名企業のボーナスポイント.
あなたが要求したように、あなたが違反/パスワードクラッキングの例を見つけるとは思いません。 256ビットのSHA-2ソルトハッシュのHMACは、現在、連邦政府のNIST標準などに適合することが許容範囲内であると考えられています。 [連邦規格では、HMACは少なくとも112ビットである必要があります。]
ただし、あなたの懸念には、ソリューションの寿命が長いというIMOのメリットがあります。 SHA-2は段階的に廃止されます。 SHA-3は2か月前にNISTによって正式に公開されました。 FIPS202 同僚が提唱するアプローチは最後の世代なので、しばらくは問題ないはずですが、正式に非推奨になるまでの期間は長くありません。
ところで、ハッシュ関数の反復は強力な保護の確立された方法ですが、攻撃者が反復の数を知っていると仮定すると、ブルートフォース攻撃に対して線形値を提供するだけであることに注意してください。同様に、ハッシュをソルトしない人はソフトウェア開発者のランクから外れるべきですが、ソルトはテーブルベースの攻撃に対してのみ保護します。今日、そして今後も、本当の問題はブルートフォースです。パスワードの長さと複雑さの要件は最も重要な保護であり、すべての機密アクセスに対して2FAを考慮する必要があります。
おそらく、侵害されたデータの証拠がない場所で発生した侵害を指摘することも重要です。たとえば、LastPassは「5,000ラウンドのPBKDF2-SHA256」とランダムなソルトを使用しました（ https://blog.lastpass.com/2015/06/lastpass-security-notice.html/ ）。違反以来、マスターパスワードが破られた兆候はありません。
データベースが壊れているかどうかを常に把握しているとは限りません。たとえば、データベースが盗み出されてユーザーのマシンに常駐している場合でも、クラックされたパスワードがPastebinに投稿されるとは限りません。
パスワードのリセットが発行される前に、最小限のユーザーアカウントが危険にさらされるだろうというステートメントでアイデアを紹介することは良いセグエです。したがって、リスクと法的責任を軽減します。
これは、この種の決定を処理する方法ではありません。
セキュリティ対策は、使いやすさ、コスト、セキュリティの間のトレードオフです。リスク軽減テクノロジーを評価するには、その選択の3つの要素すべてを評価する必要があります。
- ユーザーにとっても、それを展開して管理する人々にとっても、このテクノロジーを使用するのはどのくらい難しいですか？
- 特定のリスクを軽減する上で、そのソリューションはどの程度効果的ですか？
- そのテクノロジーを実装して運用するにはどれくらいの費用がかかりますか？
あなたのケースでは、業界標準のパスワード導出システムを使用しても、使いやすさへの影響はごくわずかです。非常に制限の厳しいデバイスを使用している場合を除き、ユーザー（それらすべて）への影響はほとんど無視できます。
そのキー拡張ステップ自体を追加すると、2つのセキュリティ上の利点が提供されます。ブルートフォースによって特定のパスワードを解読することがかなり難しくなります。また、標準のパスワード導出機能を使用する場合は、非常に堅固な基盤になります。ユーザーを保護するために考えられるすべての手段を使用したとしましょう（パスワードが侵害された場合でも、信頼を取り戻そうとするときに、これは重要な要素ではありません）。
コストに関しては、システムの構築方法に大きく依存します。長い必須の計算フェーズを操作に追加すると、インフラストラクチャのコストが増加する可能性があります。同じ数のユーザー認証リクエストを処理するには、より多くのCPUサイクルが必要になります。もちろん、どれだけ正確にあなただけが理解できるものです。
OWASPにはすばらしい パスワードストレージチートシート があります。これらのガイドラインは基本的に、ほとんどの情報セキュリティ専門家がクライアントに推奨するものです。 work factor のセクションを必ず参照してください。
また、この投稿をご覧ください パスワードを安全にハッシュする方法