1

私は自分のウェブサイトに永続的なログインを実装するための最善の (そして最も安全な) 方法を研究してきました。

ユーザーがログインすると、ユーザーの ID/ユーザー名とランダムに生成された番号 (トークン) を含む Cookie が作成されます。トークンは、ユーザー ID/ユーザー名とともにリレーショナル テーブルに格納されます。メンバー専用ページが読み込まれるたびに、この Cookie がリレーショナル テーブルに対してチェックされ、存在し、トークンと一致する場合、ログインは有効であり、ページを読み込むことができます。ただし、そうでない場合、ログインは無効であり、Cookie は破棄され、ユーザーはログインするように求められます。

I was thinking... to save on database access every single time a page is loaded, I could also have a session variable that lasts, say, 10 minutes, and is destroyed automatically when the browser closes. If the session is alive, then it's refreshed and the user can proceed. If the session expires, but the cookie is still valid, check the cookie, reset the token, store that new token in the database (while eliminating the old token, or storing it in an archives table for future reference), and reset the cookie using the new token value.

However, what would the session contain? And how could the session not simply be faked with some JavaScript? Perhaps the session contains a one-way encrypted hash? What would be used to generate that hash (user ID, etc.)?

私はここからどこへ行くべきかについてちょっと立ち往生しています。私はクッキーのものを取得しますが、一時的なセッションを使用する (ページがロードされるたびにデータベースへの呼び出しが繰り返されるのを避けるため) ことはできません。何か助けはありますか？ありがとう。

4

2 に答える 2

2

RFC 4122によると、UUID の使用は推奨されません。

UUID を推測するのは難しいと思い込まないでください。セキュリティ機能として使用しないでください。

次のすべての情報を組み合わせてハッシュに乗算し、サーバーに保存されている公開鍵を使用して暗号化することをお勧めします.

  • UserId (または、登録時に各ユーザーに対して生成されたユーザー UUID)
  • 暗号化された彼/彼女のパスワード (各ユーザーごとの暗号化のための秘密鍵と見なされます)
  • タイムスタンプ
  • クライアント オペレーティング システム
  • クライアント ユーザー エージェント (ブラウザ名)

トークンを保存するには、大企業で頻繁に使用されるmemcacheを使用するか、永続性に重点を置いている場合はredisを使用できます。

Cookieの詳細については、Cookie に次の属性があることを確認してください。

  • HTTP のみのクッキー
  • 安全なクッキー
于 2014-02-08T09:10:50.250 に答える
1

Cookie は問題ないはずですが (代わりに、HTTP ヘッダーに保存することもできます)、ユーザー名/ID を Cookie に保存する必要はないと思います。トークン自体で十分です。UUIDをトークンとして使用できます。それをユーザー名と last_access_timestamp と共にデータベース テーブルに保存します。また、リクエストごとにトークンのみを (Cookie または HTTP リクエスト ヘッダーで) 送信します。私の意見では、セッションを実装するにはそれで十分です。

ユーザーのログインが成功するとトークンが生成され、データベースに格納されてユーザーに渡されます。ユーザーが Web ページにアクセスするたびに、トークンが要求で渡され、検証されます。有効な場合、last_acces_timestamp が更新され、ユーザーは続行できます。検証のルックアップはトークンによって行われ、ユーザー名を使用して認証と承認を行うことができます。トークンが無効または期限切れの場合、ユーザーをログイン ページに転送します。

期限切れのセッションをデータベースから削除するには、cron ジョブを使用するか、新しいセッションの作成時に定期的に行うことができます。

パフォーマンス上の理由から、メモリ内のハッシュマップにセッションを保存することを考えるかもしれません。データベースを常に更新するのはコストがかかる可能性があるためです。

また、人々がトークンを盗聴するのを防ぐために、HTTPS を使用することも検討してください。

数か月前に、次の方法でこれを解決しました: https://stackoverflow.com/questions/12829994/java-custom-session-implementation-expired-sessions

于 2012-12-19T20:10:30.230 に答える