HMAC秘密鍵クライアントストレージ
今日、RESTfulクライアント（Javascript）アプリケーションでのクライアント認証にHMACと秘密鍵を使用することについて、数多くの記事を読みました。それでも、理論のセキュリティギャップを埋めるプロセスを透過的に説明できる単一のソースは見つかりません。
秘密鍵は秘密であることになっています。つまり、その特定のクライアントとサーバーだけが鍵を知っている必要があります。秘密鍵はネットワークを介して転送するべきではないため、電子メールなどの安全な媒体を介して送信する必要があります。 SSL/TLSは使用しないため、ログイン時にサーバーからの応答として秘密鍵を送信することはできません。
セキュリティについて質問するとき、私には意味がありません。ユーザーが私のアプリケーションのメールにアクセスする唯一の理由は、（アカウントをアクティブにするための）登録にあります。
- 私の最初の考えは、Cookieは安全ではないということですが、クライアントに秘密鍵を保存する別の方法はありますか？
- ユーザーがCookieをクリアすると、秘密鍵は失われます。 Cookieがなくなるたびに新しい秘密鍵を使って別のメールを送信するのはあまり論理的ではありません。これはユーザーには意味がありません。
- ユーザーは複数のクライアントを使用し、クライアントごとに個別の秘密鍵を生成する必要があります。登録時にキーを設定することは、オプションのようには聞こえません。
ユーザーがログオフするとき（または一定の有効期限が切れたとき）にキーを保持する理由がないため、ユーザーがログインするときにクライアントが秘密キーを手に入れることが私にとって意味がある唯一のことです。
だから問題は簡単です：
ユーザーはログイン時にどのように秘密鍵を取得し、安全に保管するためにクライアントのどこに保存しますか？
私はこれを理解することができないようであることに少し驚いています。同じ質問に対する多くの答えが低木を打ち負かしているように見えますが、私を理解させるようなスイートスポットに到達することはありません。
編集：もう1日調査した結果、SSL接続が本当に必要であると結論付けることができました。他の方法では見えません。
とにかく、秘密はクライアントとサーバーの両方に到達する必要があります。
これが本当である場合、私が読んだ多くのWebサイトやブログが、Basic Auth + SSLの代替としてHMACを使用することを指摘している理由がわかりません。サーバーとクライアントの@ログイン時に秘密鍵を共有する透過的な方法がない場合、私にはHMACを使用する意味がまったくありません。
RESTful環境と同様に、これは残念なことに、サーバーに送信されるすべてのリクエストは個別に認証される必要があります。
私のアプリケーションは、架空の大量の人に対して多くのリクエストをサーバーに送信することになっています。SSLが引き起こすオーバーヘッドを恐れています。
これを間違って見た場合は、修正してください。
はい、SSLは少なくとも「コード」をクライアントに転送するために必要です。つまり、すべてのHTMLとJavaScriptです。クライアントがログインするときにSSLを使用してキーを転送し、安全なCookieを使用して、クライアント側のJavaScriptコードにその安全なCookieに含まれるキーを使用して非SSL HTTPリクエストを送信させることができます。ただし、これにより多くの複雑さが増し、JavaScriptの暗号化はWebブラウザーおよびWebサーバーでのSSL実装よりも低速になる可能性が高いため、SSLは単純でエラーが発生しにくく、おそらくいずれにしても高速になります。さらに、データの機密性が非常に低い場合を除き、リクエストとレスポンスを暗号化する必要があります。その場合は、いずれにしてもSSLが必要になります（JavaScriptで暗号化しようとしてもメリットはありません）。