パスワードをクッキーに保存しないのはなぜですか？
初心者の質問があります-
Itisoftensaid クライアント側のCookieにプレーンテキストのパスワードを保存しないでください。 （私はWebブラウザーのCookieを想像していますが、これは一般的に当てはまるはずです。）しかし、単純なWebアプリでは、プレーンテキストのセッションIDをCookieに保存することがよくあります。
詳しく説明するために、このモデルを使用してサイトを保護することがよくあります。
- ユーザーは、クライアントマシンでユーザー名とパスワードを入力します。これらは、安全な（HTTPS）接続を介してサーバーに送信されます。
- サーバーはパスワードをハッシュし、データベースに対して検証します。パスワードが正しいと仮定すると、サーバーはセッションIDを生成し、それを応答の本文と一緒にクライアントマシンに返します。
- クライアントはプレーンテキストのセッションIDをCookieに保存します。クライアントが別のサーバーを呼び出すたびに、セッションIDは安全な接続を介してサーバーに返送されます。
- 非アクティブな状態がx分間続くと、セッションは期限切れになり、セッションIDはそのユーザーに対して有効とは見なされなくなります。
ただし、このモデルを使用しないことを強くお勧めします。
- ユーザーは、クライアントマシンでユーザー名とパスワードを入力します。これらはプレーンテキストでクライアント側のCookieに保存されます。次に、安全な（HTTPS）接続を介してサーバーに送信されます。
- サーバーはパスワードをハッシュし、データベースに対して検証します。パスワードが正しいと仮定すると、サーバーは応答を返します。
- クライアントが別のサーバーを呼び出すたびに、パスワードは安全な接続を介してサーバーに送り返されます。
- 非アクティブな状態がx分間続くと、Cookieが期限切れになり、パスワードはクライアントのマシンに保存されなくなります。
最初のモデルが安全であるのになぜ2番目のモデルが安全でないと考えられるのですか？確かに、2番目のモデルでは、悪意のあるCookieリーダーがブラウザからパスワードを盗む可能性があります。しかし、どちらのモデルでも、悪質なキーリーダーがIOサブシステムからパスワードを盗む可能性があります。これが、2番目のモデルが使用されない唯一の理由です。または、クライアントにパスワードを保存する際に、私にはわからない、もっと大きな問題がありますか？
ありがとう！
2番目のモデルに対するいくつかのポイント：
- データベースリークが発生した場合のブルートフォースの実行を遅くするために、パスワードのハッシュにはかなりの時間がかかります。すべてのリクエストでパスワードをチェックすることは、リソースの無駄です。
- CookieはXSS攻撃に対して脆弱である可能性があり、パスワードが盗まれるのは、セッションが盗まれるよりも悪いです（パスワードはそれほど頻繁に変更されず、複数のサイトで再利用される傾向があります）。
- 通常、Cookieは暗号化されずにクライアントに保存されます。
- パスワードを変更する必要があるため、セッションを簡単に無効にすることはできません。
- シングルサインオンシステムとは完全に互換性がありません（@CBHackingに感謝）
パスワードの代わりにパスワードハッシュを保存する方がはるかに優れているわけではありません。パフォーマンスの問題は解決しますが、パスワードハッシュをリークしてブルートフォースする可能性があり、セッションを簡単に無効にしたり、複数の同時セッションを持つユーザーの場合。
前の回答に完全に同意します。ソリューションのセキュリティを評価するのに役立つ、もう少しコンテキストがあります。
最初のモデルは、Cookieを使用した典型的なセッション管理です。 すべての主要なユースケースをサポート セッションに必要。
2番目のモデルは Basic Auth にいくらか似ていますが、認証データが（HTTPOnlyフラグを設定せずに）リークするCookieを介してクライアントに公開される可能性がある点が異なります。 HTTPOnlyフラグが設定されている場合、基本認証に非常に近く、そのプロパティのほとんどを共有しています：信頼できるタイムアウトがない、SSOサポートがない、パスワードの漏洩、複数のセッションがないなど。
私は Web Authentication Guide をまとめて、どの認証方式があなたのユースケースに最適であるかを決定するのを助けます。見てみな！