Webアプリケーションでハッシュコショウは可能ですか？
正しくハッシュすることについて、ここでいくつかの記事といくつかの質問を読みました。ハッシュ、ソルト、特にペッパーの追加は主にサーバー側の使用例ですが、JavaScriptベースのWebアプリケーション（クライアント側）でこれらのプラクティスの多くを実装する可能性に関心があります（自分でセキュリティメカニズムの発明について話しているのではありません）。 サーバー側に追加して。
ハッシュ
...以前の多くの質問で回答されているように、クライアント側では完全に可能ですが、ハッシュされたパスワードをクライアントハッシュ自体で置き換えないことがサーバー側で依然として重要です。さらに、サーバーが侵害された場合に備えてパスワードが保護されます。安全でない接続のためにそれを手に入れる攻撃者は、平文ではなくレインボーテーブルを使用してパスワードを見つける必要があります。
塩
...一意である必要がありますが、必ずしもハッシュされたパスワード自体よりもプライベートではなく、同じデータベースに保存されます。同様に、クライアントソルトは一意のユーザー名にすることもできますが、ユーザーがハッシュされたソルトパスワードに加えてクリアテキストで送信される場合、ソルティングは攻撃者には関係ありません。 （しかし、ユーザー名がなければ、saltは追加のセキュリティを提供します。）
コショウ
...秘密にする必要があり、アプリケーションのすべてのパスワードで共有され、ハッシュとソルトを含むデータベースとは別に保持されます（たとえば、データベースでSQLインジェクションを成功させた攻撃者がアプリケーションにアクセスできない可能性があるため、アプリケーションでは）。 WebアプリケーションのJavaScriptにハードコードされたペッパーが含まれている場合、攻撃者はそれを簡単に見つけて、ペッパーを役に立たなくする可能性があります。
（再度：クライアント側のアクションに関係なく、サーバー側でハッシュ、ソルト、ペッパーを実行すると仮定します）
送信中にパスワードのセキュリティを強化するためにクライアント側にペッパーをかける方法はありますか？私はセキュリティの経験がなく、攻撃者がクライアントになるか、クライアントのペッパーを含むサーバーのトラフィックをフェッチできるため、そのようなペッパーを安全に含める方法を考えることができません。
「pepper」の使用例は、攻撃者がパスワードハッシュを取得したが、pepper値を取得しなかった場合に、パスワードハッシュを解読できないようにすることです。そのようなシナリオの1つは、データベースの内容は読み取ることができますがファイルの内容は読み取れない、制限されたSQLインジェクションです。
同様のセキュリティを提供する1つの方法は、非対称暗号化を使用することです。クライアントは、サーバーの公開鍵を使用してパスワードハッシュを暗号化します。サーバーには対応する秘密鍵があり、パスワードハッシュを復号化して確認できます。このようにして、クライアントはパスワードハッシュをサーバーのみが使用できるようにする作業を実行できます。
クライアント側でsaltを使用する理由はありません。ソルトサーバー側の使用には、3つの目的があります。
- これにより、アリスのパスワードの回復に費やされたオフラインのクラッキング作業は、ボブのパスワードの回復には役立ちません。 （アリスとボブが異なる塩を持っている限り。）
- 事前に計算されたハッシュを利用するオフラインのクラッキング技術を防ぎます。 （塩が予測できない限り。）
- これにより、パスワードハッシュデータベースのダンプを持つ誰かが、2つ以上のアカウントが同じパスワードを使用しているかどうかを判断できなくなります。 （塩が一意である限り）。
クライアントがユーザーのパスワードのハッシュを受け取ることはありません。保存されたハッシュに対して入力をチェックするのはサーバーの仕事です。クライアントにパスワードハッシュを与えた場合は、オフラインクラックを有効にしています。
ソルトは、（オフラインで）可能な限り多くのパスワードハッシュを簡単に解読する方法です。彼らは防御の層です*ただし、パスワードハッシュが漏洩する危険性を排除するものではありません。
（リークされたハッシュはオフラインでのクラックを可能にします。つまり、サーバーはレート制限やアカウントロックアウトを課すことができません。サーバーは、パスワードがクラックされることからユーザーを保護することはできません。また、ログイン資格情報が侵害されたかどうか、またはそれが侵害されたかどうかを知ることもできません。）
Saltクライアント側を追加する必要がある場合は、パスワードを渡しますwrong。保存されているパスワードハッシュのみにソルトが必要です。パスワードハッシュの公開は可能な限り制限する必要があります。
* Saltingは、個々のアカウントがターゲットにされるのを防ぎません。また、クラッカーが1つのアカウントのみを侵害する必要がある場合にも役立ちません。弱いパスワードを推測してすべてのユーザーを標的にし、最も弱いパスワードでアカウントをハッキングすることができます。
あなたがそれを述べたように、「コショウ」はちょうど第2の塩です。すべてのユーザーにとって同じであり、クライアントに提供した場合、予測不可能ではありません。秘密でない場合は何も追加しないため、クライアントに送信しないでください。
繰り返しになりますが、パスワードハッシュがない場合、「pepper」を入力に追加しても意味がありません。
「pepper」の代替定義の1つは、単にパスワードのハッシュとソルトを暗号化することを指します。これは、暗号化が適切に行われ、使用されるキーがすべてのパスワードハッシュと共に漏洩しないことを前提として、オフラインでのクラッキングに対する完全な保護を提供します。
このタイプのコショウは良い考えですが、完璧ではありません。パスワードハッシュのコピーが漏洩した場合にのみ、オフラインクラックを防ぐのに役立ちます。 （たとえば、SQLインジェクションを使用するか、キーが同じドライブに格納されていない場合、誰かがサーバーのハードドライブからハッシュデータベースをコピーします。）サーバーの完全な侵害から保護しません。
[〜＃〜] https [〜＃〜]を使用します。クライアント（ブラウザ）はすでにそれを実装しています。独自の暗号化を実装するよりも簡単で、とにかくHTTPSを使用します。
クライアント側で行うパスワード処理の種類に関係なく、通信が暗号化および認証されていない場合、ユーザーセッションは他の方法で脆弱になります。 （たとえば、セッションCookieの盗用や中間者攻撃など。）
さらに、クライアントまたはスクリプトをロードするページに送信されるJavaScriptが認証されていない場合は、スクリプトまたはページが改ざんされて、クライアント側のハッシュを無効にする可能性があります。
他の回答では、ソルトのハッシュ化とペッパーの使用がパスワードの解読を困難にする方法をカバーしています。転送中のユーザー資格情報のセキュリティに関する限り、HTTPS Everywhereがそれを処理する必要があります。
攻撃者がHTTPS接続を危険にさらし、Webブラウザーとサーバー間のアプリケーショントラフィックを見ることができるとします。これが攻撃シナリオであると想定すると、セキュリティの別の層（クライアント側のハッシュ/暗号化）を追加したとしても、攻撃者はクライアントのブラウザに提供されるWebページを変更し、フィッシングを介してユーザーパスワードを取得するのではなく、比較的簡単です。クライアント側のセキュリティメカニズムをリバースエンジニアリングする。