13

私はRememberMeがどのように機能し、Spring Securityでどのように機能するのか興味がありますか？

サーバーが長期間有効なCookieをクライアントに送信することを理解しています。そして、クライアントはCookieを送り返し、サーバーにはリレーションを持つハッシュマップのようなものがあるため、サーバーはクライアントを認識できますcookie --> session。

サーバー[Tomcat]が再起動された後、サーバー[サーバー側アプリケーション]がCookieによってクライアントをどのように認識するのかわかりません。

cookie-sessionSpring Securityは、サーバーがシャットダウンする前に、どのように、どこにマップを保存しますか？サーバー固有ですか（つまり、Tomcat、Jettyなどで何か別のことが起こります）？

PS Spring Securityと再デプロイに関連するもう1つの問題：チェックマークを付けRememberMeてログインしなくても、再デプロイ後約3分間認識されます。修正可能ですか？

4

2 に答える 2

12

Spring Securityのドキュメントでは、これが実際にどのように機能するかについて説明しています。

このアプローチでは、ハッシュを使用して、有用な記憶戦略を実現します。本質的に、Cookieは、対話型認証が成功するとブラウザに送信され、Cookieは次のように構成されます。

base64(username + ":" + expirationTime + ":" + md5Hex(username + ":" + expirationTime + ":" password + ":" + key))

..。

そのため、remember-meトークンは、指定された期間のみ有効であり、ユーザー名、パスワード、およびキーが変更されない場合に限ります。特に、これには潜在的なセキュリティの問題があり、キャプチャされたremember-meトークンは、トークンの有効期限が切れるまで、任意のユーザーエージェントから使用できます。これは、ダイジェスト認証の場合と同じ問題です。

基本的に、Cookieには、ユーザー名、パスワード、有効期限、およびキー（指定したもの）が含まれ、これらはすべて一緒にハッシュされます。ブラウザがこのCookieの内容をサーバーに送信すると、Spring Security：

  1. 指定されたユーザー名のバックエンドからパスワードを取得します
  2. md5Hex()データベースからユーザー名/パスワードなどを計算し、Cookieの値と比較します
  3. それらが一致する場合-あなたはログインしています！一致しない場合は、偽造されたCookieを提供したか、ユーザー名/パスワード/キーの1つが変更されています。

ここでの基本的な仮定は、ハッシュ関数（md5Hex()上記の部分）は、データの一部を一方向に簡単にエンコードする方法を提供しますが、元に戻す（md5Hexテキストからパスワードを回復する）のは非常に難しく、実用的ではないということです。

于 2010-06-29T16:48:37.893 に答える
10

セッションCookieとRememberMeCookieを混同しないでください。

セッションCookieはサーバー（Tomcatなど）によって送信され、着信要求をセッションに関連付けるために使用されます。

覚えておいてくださいCookieは、さまざまなセッションでクライアントを認証するためにSpring Securityによって送信されます（たとえば、元のセッションの有効期限が切れた後、またはサーバーの再起動後）。

Remember Me cookieによってユーザーを認証するために、SpringSecurityは2つの戦略を提供します。

  • TokenBasedRememberMeServices-デフォルトで使用されますが、安全性は低くなります-cookieにはパスワードとその他のデータのハッシュが含まれます
  • PersistentTokenBasedRememberMeServices-より安全で、データベースへのアクセスが必要です-cookieにはデータベースに保存されている一意の識別子が含まれています
于 2010-06-29T16:56:51.777 に答える