2

ユーザー向けの簡単なHTTP覚えている認証システムを作成しようとしています。

私のユーザーはそのように表現される可能性があります

{
"email" : "foo@bar.com",
"password" : "8EC41F4334C1B9615F930270A4F8BBC2F5A2FCD3" // sha1 hash of password
}

したがって、私の考えでは、有効期限が無期限（非常に長い）のCookieを作成する必要があります。このCookieには、データベースからユーザーをフェッチしてユーザーをログインさせるための何らかの情報が保持されます。

私の最初のアイデアは、単にemail:password文字列をCookieとして保存することでした。ユーザー自身以外にその種の情報を実際に生成できる人はいないので、これは良いことだと思いました。データベースの内容usernameとを比較するだけで、ユーザーを非常に簡単に取得できました。password

しかし、それでは、これはあまり良くないと思いました。これにより、パスワードダイジェストが事実上2番目のパスワードに変換され、クリアに保存され、すべてのリクエストでネットワークを介して渡されます。

signatureそのため、ユーザーがログインするたびに生成できるのではないかと思いました。これは基本的に、データベースのユーザーオブジェクトに直接格納されるランダムハッシュです。

ユーザーがログインすると、保存されるこの署名が生成され、Cookieがこの署名を保持します。Webサイトにアクセスするたびに、サイトはどのユーザーがその特定の署名を持っているかを確認し、ユーザーをログインさせます。ログアウトするとCookieが効果的に消去され、新しいログインで新しいランダムな署名が生成されます。

このアプローチは他の脆弱性を考慮に入れていますか？

私はおそらくこれのためにすでに作成されたライブラリを使用する必要があることを知っていますが、これは単にWebセキュリティの演習にすぎません。

4

2 に答える 2

1

これは基本的に、ログイン時にほとんどのサイトが行うことです。はい、Cookieはユーザーの「セッション」の一意の識別子を保持する必要があります。Cookieは基本的にランダムである必要があります。ブラウザセッション間で永続化するかどうかはあなた次第です。

認証DBのCookieとともに、エントリが作成されたときのタイムスタンプも保存します。N秒より古いCookieは無効と見なされます（Nを好みに設定してください）。Cookieが使用されるたびにタイムスタンプをリセットして、アイドル状態のセッションがタイムアウトするようにすることができます。

同じユーザーが複数のセッションを持ちたい場合があることに注意してください（自宅と職場の両方からEメールアカウントにログインしたことがありますか？）。したがって、ここでの概念は実際にはユーザーではなく「セッション」です。

于 2011-06-07T15:26:18.897 に答える
0

脆弱性の観点はどちらも同じです！ただし、Cookieの盗用と関連するメカニズムは、ブラウザが十分にスマートになっているため、心配する必要はありません。

2番目のアプローチは、Cookieに電子メールアドレスが含まれていないため、プライバシーの観点からも優れています。そして、それはあなたの場合、ランダムハッシュを生成してそれをDBに保存しているsessionIDを保存するのと非常に似ているようです。

しかし、最初のアプローチを使用する方が賢明だと思います。ダイジェストに別のレイヤーを追加し、アルゴキーまたは秘密キーを使用して暗号化することができます。より安全な側にいること。

于 2011-06-07T15:27:26.200 に答える