パスワードの再利用が問題にならないときに、パスワードをソルトおよびハッシュする強力な理由はありますか？
私は、ランダムに生成された（ユーザー提供ではない）一意の文字列を使用してAPIを消費するサービスを認証する（開発中の）システムを処理しています。現在、これらの文字列はデータベースにプレーンテキストで格納されています。
これらの文字列がソルトおよびハッシュされるように、このシステムを再設計する大きな理由があるかどうかを知りたいのですが。
パスワードをソルトハッシュとしてのみ保存する理由についての私の理解は次のとおりです。
- 攻撃者がデータベースにアクセスする可能性があります。
- この時点で、失うことはほとんどありません。攻撃者は既に顧客のデータにアクセスでき、顧客が望むほとんどすべてのことを実行できます。ユーザーパスワードは重要なポイントです。 ただし...
- ユーザーが他のものに同じパスワードを使用している可能性があります。適切にソルト処理およびハッシュ処理を行わないと、攻撃者は盗んだ資格情報を使用して、システムとは何の関係もない他のリソースを制御できます（同じユーザーを共有するほか、パスワードの習慣が悪い）。
言い換えれば、パスワードをソルトおよびハッシュするポイントは、パスワードの再利用による影響からユーザーを保護することです。ただし、私の場合、パスワードの再利用は重要ではありません。
これらの「パスワード」もソルトしてハッシュするようにシステムを変更する強い理由はまだありますか？
編集：
これらのAPIキーの少なくともsomeは、とにかく広く分散しているアプリケーションに埋め込まれることになります。 APIキーだけでは、すべての機密情報にアクセスするのに十分ではありませんではありません。ほとんどの場合、通常のユーザー名とパスワードも必要です。特別な権限を持つ特定のAPIユーザーは、IPアドレスによって制限されます。
それはあなたが考えていなかったかもしれない考慮事項がある公正な質問です：
- 攻撃者がデータベースのすべてにアクセスせずにデータベースの一部にアクセスできる方法があるため、ポイント2は正確ではありません。 SQLの脆弱性と同様に、コーディングエラーはデータをリークする可能性があります。攻撃者はパスワードのダンプのみを取得する可能性があります
- パスコードをハッシュして保存していない場合は、おそらくそれらを平文で送信しているでしょう。その場合、SSLを正しく使用していなければ、盗聴される可能性があります。これらをハッシュ化することで、送信に対する攻撃を徹底的に防御できます。
- 保存されたパスワードのハッシュは、デューデリジェンスとセキュリティへの取り組みを示しています。違反が発生し、パスワードをハッシュ化していないことが判明した場合は、仮説を立てても、見た目が悪くなります。あなたが監査された場合、それは同様に悪く見えるでしょう
私のアドバイスは、パスワードをハッシュ化することです。それは十分簡単で、その利点はそこにあります。
私は実際にこの正確な問題を以前に考えました。 APIキーが基本的に挿入にのみ使用される場合、実際の問題は、キーのリークとユーザーのアカウントへの不正なデータの取得です。本当に重要なこと、つまりユーザーによるデータへのアクセスについて、適切なセキュリティ管理を行っているようです。これらを必ずしもハッシュする必要があるとは思いません。理想的には、認証クレデンシャルは書き込みのみで読み取りも含めてハッシュ化する必要がありますが、システムはすでに構築されているため、変更するには多大な労力が必要になることを理解しています。 APIキーを秘密にして共有しないようにする必要があることをユーザーが認識していることを確認します。