私は維持するためにアプリを継承していると私はちょうど発見したことから返されたJSON、ユーザがログインに成功したログインが含まれる場合：塩と暗号化されたパスワードの両方を漏らすセキュリティリスクとは何ですか？
塩と暗号化されたパスワードを持つことが一般的に塩の目的を無効にすることを思えます。
ブルートフォースまたはルックアップテーブルの攻撃がクラッキングアプローチとして再び利用可能になりました。
私はこれを訂正していますが、それ以上の脅威はありますか？
これは最高ではありませんが、一般的に塩を開示することはOKです。あなたは秘密にされているpepperを考えています。
塩漬けされたハッシュは、ブルートフォース攻撃を防ぐためのものではありません。 rainbow attackを防ぐことを意図しています。ハッシュアルゴリズムの入力値に塩を含めることによって、ハッカーが可能な塩ごとにルックアップテーブルを作成しない限り、ルックアップテーブルを事前計算することは不可能になります。
あなたの洞察力と有益な答えJohnに感謝します。私は "コショウ"について聞いたことがなく、私が初めてそれを読んだときにあなたがジョークを作っているかもしれないと思った。 – aero
私の意見では、パスワードを忘れた場合でも、フロントエンドが必要としない情報を漏らしてしまい、攻撃者がパスワードを取得する可能性があります。つまり、攻撃者がその情報を取得した場合でも、すべての可能なパスワードの組み合わせがその塩と連結されている（またはパスワード辞書をその塩でハッシュしている）が、網羅的な検索を必要としますが、彼は退屈になるまで、または実際のパスワードを取得するまで、彼が望むほど多くの異なるパスワードを試すことができます。
誰かが違うパスワードで認証しようとしている攻撃者と同じだと考えているかもしれませんが、主な違いは、オンライン攻撃ではログイン試行回数を制限できるため、オフライン攻撃では、彼が望むだけの数のパスワードを試すことができます。
これは、完全なオブジェクトの代わりにブール値を送信するだけで回避できます。巨大なリファクタリングなどが必要なようではないので、修正する必要があると思います最悪の場合のシナリオでは、ユーザーを認証し続けるためにパスワードのハッシュを取得してクッキーやローカルストレージに保存するなど、その情報を使って何をするかを見てください。
@aero - 確かに、パスワードハッシュの送信が理にかなっている状況を見つけるのは難しいですが、これは非常に正当な理由なしには行えません。 – martinstoeckli
ありがとうエステバン。これは、攻撃者にパスワードをオフラインでクラックさせる機会を与えることは、セキュリティ上の脆弱性であるという点が良い点です。 – aero
salt &ハッシュがPOSTからログインハンドラまでしか利用できない場合、ここでのダメージは非常に制限されます。
データを返すwebmethod（/currentUser/getDetails）がある場合、サイト上の他の場所でのクロスサイトスクリプティング（XSS）の脆弱性がある場合、これは危険です。どの攻撃者もXSS経由でこのメソッドを呼び出し、オフラインクラッキングのためにハッシュされたパスワードと塩を取得することができます。
JSONレスポンスがoutput anti-caching headersでない場合、同じコンピュータの別のユーザーがパスワードハッシュを取得できる可能性があります。
bcryptやpbkdf2のような安全なアルゴリズムを使用する形式ではなく、パスワードハッシュがHash(Password+Salt)形式であることがさらに懸念されます。
「SilverlightFox」のおかげで、「出力のキャッシング防止ヘッダー」について、XSSの脆弱性がどのようにして現在のJSONをセキュリティに悪化させる可能性があるかを十分に検討する必要があります。 – aero
「暗号化されたパスワード」の意味は不明です。ハッシュされた（または伸ばされた）パスワードを意味しますか？それとも実際に鍵で暗号化されていますか？パスワードを平文に復号化できますか？ –
@RobNapierこんにちは。暗号化されたパスワードでは、ハッシュ（パスワード+塩）=ハッシュ結果を意味します。 – aero