0

次の設定で深刻な問題が何であるか疑問に思っています。

ユーザー名/パスワード ログイン スキーム Javascript/ajax は、サーバーからソルト値を要求します (以前の質問でソルトはシークレット値ではないことを確認しました) Javascript は、パスワードとソルトの SHA1 (またはその他) を実行します。Javascript/ajax がハッシュをサーバーに返す サーバーは、ajax 経由で送信されたものの上に別のソルト/ハッシュを適用します。

トランザクションは HTTPS 経由です。

存在する可能性のある問題について心配していますが、これがそれほど悪い設定であると自分自身に納得させることはできません. サイトでは jQuery が頻繁に使用されているため、すべてのユーザーが JavaScript を有効にする必要があると想定します。基本的に、パスワードのプレーンテキストにセキュリティのレイヤーを追加しようとしています。

4

5 に答える 5

3

いつものように、暗号化プロトコルを自分で設計する場合は十分に注意してください。

しかし、そうは言っても、私はスキームの利点を見ることができます。中間者攻撃によってパスワードが明らかになるのを防ぎ、サーバーが実際のパスワードを決して見ないようにするため、内部攻撃を防ぐことができます。一方で、man-in-the-browser、フィッシングなどから保護することはできません。

HTTP ダイジェスト アクセス認証に関するRFC 2617を一読することをお勧めします。そのスキームはあなたが提案するものに似ています。

于 2010-09-16T17:20:47.463 に答える
2

クライアントとサーバー間でソルトとハッシュを渡すすべての作業は、基盤となる HTTPS/SSL プロトコルに既に組み込まれています。JavaScript のセキュリティ層が非常に役立つとしたら、私は非常に驚かれることでしょう。シンプルに保ち、クライアント側で SSL 経由のプレーンテキストを使用することをお勧めします。サーバー側での暗号化に注意してください。

于 2010-09-16T14:54:49.010 に答える
1

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

また、クライアントがハッシュソルトについて知っておくべき理由はありません。特に共有ソルトを使用している場合は、実際にはシークレット値にする必要があります。

于 2010-09-16T14:34:06.307 に答える
0

あなたは何も得ていません。Joe Public が [表示] > [ソース] をクリックしてソルトを表示できる場合、ソルトを使用しても意味がありません。また、クライアントの入力を決して信頼しないという古い格言は、パスワード ハッシュでは 2 倍になります。

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

于 2010-09-16T14:38:46.840 に答える