一部の (特に銀行の) パスワード システムでは、ログインするためにパスワードから (指定された) 3 文字を入力する必要があります。
明らかに、ハッシュを計算するにはパスワード全体を知る必要があるため、通常のパスワードハッシュを使用してそのようなスキームを機能させる方法はありません。
そのようなシステムは、これを機能させるために一般的にサーバー側に何を保存しますか?
彼らはパスワードをプレーンテキストで保存しますか、それとも各文字の個別のハッシュ、または何を保存しますか?
2648 次
1 に答える
18
ご指摘のとおり、パスワードの部分文字列のみを使用して認証が行われる場合、標準のパスワード ハッシュ スキームは機能しません。このようなシステムを実装するには、いくつかの方法があります。
パスワードを平文で保存します。
- シンプルで簡単に実装できます。
- データベースが侵害された場合、安全ではありません。
- ハッシュ化または暗号化されたパスワード ストレージを要求する規制に準拠していない可能性があります (ただし、低レベルのデータベース暗号化を使用すると、それを回避できる可能性があります)。
暗号化されたパスワードを保存し、復号化して確認します。
- 暗号化キーも侵害された場合、プレーンに保存するより安全ではありません。
- パスワードを平文で保存することを禁止する規制を満たしている可能性があります。
- 専用のハードウェア セキュリティ モジュールまたは別の認証サーバーを使用して、より安全にすることができます。これにより、キーが保存され、暗号化と部分文字列の検証のためのブラックボックス インターフェイスが提供されます。
すべての (または十分な数の) 可能な部分文字列のハッシュを保存します。
- 他のソリューションよりもはるかに多くのストレージ スペースが必要です。
- 各部分文字列が個別に攻撃される可能性があるため、データベースが危険にさらされた場合でも、パスワードは力ずくでかなり簡単に回復できます。
k -out-of- nしきい値秘密共有を使用します。
- 複数のハッシュを保存するよりも必要なスペースが少なくて済みますが、パスワードをプレーンまたは可逆暗号化を使用して保存するよりも多くのスペースが必要です。
- 部分文字列の検証のためにパスワードを復号化する必要はありません。
- データベースが危険にさらされた場合でも、ブルート フォース攻撃の影響を受けやすい:パスワードのk文字を推測できる人は、残りを回復できます。(実際、一部の実装では、k -1 文字で十分な場合があります。)
最終的に、これらのスキームはすべて、データベースが侵害された場合のブルート フォース攻撃に対する脆弱性に悩まされます。これの根本的な理由は、典型的なパスワードの 3 文字の部分文字列 (実際には、特に強力なパスワードでさえも) にはあまりエントロピーがないため、クラックするのに多くの推測を必要としないからです。
これらのうちどれが最適ですか? それは言うのは難しいです。これらのスキームのいずれかを選択する必要がある場合、暗号化と検証を処理する別のサーバーまたは HSM を使用して、強力な対称暗号化 (AES など) を使用して暗号化されたストレージを選択するでしょう。そうすれば、少なくとも、フロントエンド サーバーを侵害する攻撃者は、データベースをコピーしてオフラインで攻撃することはできません (ただし、効果的なレート制限を実装していない場合、HSM にブルート フォース攻撃を仕掛けることはできますが)。 ）。
ただし、パスワードの一部のみを認証に使用するという考え全体には大きな欠陥があると思います。特に限定されたいくつかの攻撃シナリオ (たとえば、は 1 つの認証イベントしか観測できず、同じチャレンジを受けるまで試行を続けることはできません) が、認証の成功に必要な情報量を減らすことによってセキュリティを根本的に弱めます。部分的なパスワード認証が対処するはずのセキュリティ上の懸念に対しては、TANなどのはるかに優れたソリューションがあります。
于 2011-11-22T14:21:38.413 に答える