HTTPS上のクライアント側のハッシュ/塩漬け

Question

次のセットアップで深刻な問題が何であるか疑問に思っています。

ユーザー名/パスワードログインスキームJavaScript/ajaxは、サーバーから塩値を要求します（以前の質問で確立した塩は秘密の値ではありません）JavaScriptは、パスワードと塩のSHA1（またはその他）を事前に形成します。 JavaScript/ajaxハッシュをサーバーに戻しますサーバーは、Ajaxを介して送信されたものの別の塩/ハッシュオントップを適用します。

トランザクションはHTTPSを超えています。

私は存在するかもしれないが、これがセットアップの悪いことだと確信することはできない問題を心配しています。 jqueryがサイトで頻繁に使用されているため、すべてのユーザーがJavaScriptを有効にする必要があると仮定します。基本的に、パスワードのプレーンテキストにセキュリティの追加レイヤーを追加しようとしています。

Answer 1

クライアントとサーバーの間に塩とハッシュを渡すことのすべての努力は、すでに基礎となるHTTPS/SSLプロトコルに組み込まれています。 JavaScriptのセキュリティレイヤーが非常に役立つかどうかは非常に驚くでしょう。シンプルに保つことをお勧めし、クライアント側のSSLを介してプレーンテキストを使用することをお勧めします。サーバー側の暗号化について心配します。

Answer 2

いつものように：暗号化プロトコルを自分で設計することに非常に注意してください。

しかし、そうは言っても、私はスキームの利点を見ることができます。それ 意思 中間の攻撃とそれを通して明らかにされるパスワードから保護し、それは 意思 サーバーが実際のパスワードを表示しないことを確認してください。したがって、内部攻撃を防ぎます。一方、それはブラウザの男、釣りなどから保護しません。

あなたは読み通したいかもしれません RFC 2617 HTTP Digest Access Authenticationについて。そのスキームは、あなたが提案するものに似ています。

Answer 3

これは追加のセキュリティを追加しません。 JavaScriptコードはクライアントに存在するため、ハッシュアルゴリズムがわかっています。この場合、クライアント側のハッシュを行うことから何も得られません。

また、クライアントがハッシュ塩について知っておくべき理由はありません。実際に したほうがいい 特に共有塩を使用している場合は、秘密の価値になります。

Answer 4

あなたは何も得ていません。 Joe PublicがView> Sourceをクリックすることでそれを見ることができ、クライアントの入力を信頼しないことについての古い格言は、パスワードハッシュのために2倍になる場合、塩に意味がありません。

SHA-1には潜在的な脆弱性があるため、実際にセキュリティを増やしたい場合は、SHA-2ベースのハッシュ（SHA-224/256/384/512）を使用してください。 NISTは、衝突攻撃に対して脆弱なアプリケーション（パスワードハッシュなど）にSHA-1を推奨しなくなりました。

Answer 5

私は受け入れられた答えに100％反対し、いかなる状況でもクライアントを離れることは決してないと言うでしょう。それは常に塩漬けしてハッシュする必要があります。常に、例外なく。

2つの理由...。クライアントは、すべてのサーバーコンポーネントと内部ネットワークがTSLであることに依存してはなりません。 TSLエンドポイントは、すべての内部サーバーのサーバー証明書を生成するためにDevOpsを悩ませることができないため、プレーンテキストを使用してアプリサーバーと通信するロードバランスリバースプロキシであることが非常に一般的です。

. 。多くのユーザーは、すべてのサービスに共通のパスワードを使用する傾向があります。サーバーがパスワードをプレーンテキストしているという事実は、たとえメモリのみであっても、外部攻撃の魅力的なターゲットになります。