ウェブサイトに「私を覚えている」を実装する最良の方法は何ですか?[閉まっている]


510

ユーザーがクリックできるチェックボックスをウェブサイトに設定して、ユーザーが私のウェブサイトにアクセスするたびにログインする必要がないようにします。これを実装するには、自分のコンピュータにCookieを保存する必要があることはわかっていますが、そのCookieには何を含める必要がありますか?

また、このCookieがセキュリティの脆弱性を示さないようにするために注意すべき一般的な間違いはありますか?


5
stackoverflow.com/questions/549/…(トップアンサーのパートII)を確認してください
Frosty Z

ASP.NETを使用している場合は、codeproject.com
Articles / 779844 /

1
セキュリティSE〜で比べていくつかの非常に便利な情報がありますsecurity.stackexchange.com/questions/19676/...
b1nary.atr0phy

splattneが現在受け入れている回答は、非常に複雑です。ランダムなソースから+16バイトのトークンを作成し、ハッシュして、ハッシュ+アカウントIDをデータベースに保存します。次に、HTTPS + httpOnly Cookieでトークンをユーザー(base64エンコード)に送信します(そのため、Javascriptはアクセス/スチールできません)この方法では、トークンを推測したり、無効な推測でログアウトしたりすることはできませんが、データベースがハッキングされたとしても、データベース内のトークンを使用することはできません(ハッシュされます)。したがって、元のクライアント(またはブラウザストアからトークンを盗んだ人)のみがそれを使用できます。
Xeoncross

回答:


536

永続的ログインCookieのベストプラクティスの改善

ここで説明されているこの戦略をベストプラクティス(2006)またはここで説明されている更新された戦略(2015)として使用できます。

  1. Remember Meをオンにしてユーザーが正常にログインすると、標準のセッション管理Cookieに加えて、ログインCookieが発行さます
  2. ログインCookieにはシリーズIDとトークンが含まれています。シリーズとトークンは、適切に大きなスペースからの推測不可能な乱数です。両方がデータベーステーブルに一緒に保存され、トークンがハッシュされます(sha256は問題ありません)。
  3. ログインしていないユーザーがサイトにアクセスしてログインCookieを提示すると、シリーズIDがデータベースで検索されます
    1. 場合は、一連の識別子が存在し、ハッシュのあるトークンと一致することをシリーズ識別子のハッシュ、ユーザーが考慮される認証済み新しいトークンが生成され、トークンのための新たなハッシュは、古いレコードの上で貯蔵され、そして新しいログインクッキーは(それは再使用しても大丈夫ですユーザに発行されたシリーズの識別子)。
    2. シリーズは存在するがトークンが一致しない場合、盗難が想定されます。ユーザーは強く言葉を使った警告を受け取り、ユーザーが覚えていたセッションはすべて削除されます。
    3. ユーザー名とシリーズが存在しない場合、ログインCookieは無視されます。

このアプローチは、多層防御を提供します。誰かがなんとかしてデータベーステーブルをリークしても、攻撃者がユーザーになりすますためのドアを開けることはありません。


20
次も参照してください:stackoverflow.com/questions/549/…「改良版」バージョンを読むべきではありません
Jacco

8
これの問題は、ユーザー名をCookieに公開することですが、これはGmailが行うことです。なぜシリーズIDとトークンの両方が必要なのですか?大きなトークンは問題ないでしょうか?
Dan Rosenstark、2009

10
また、このモデルに関しては、攻撃者が盗むのを防ぎ、Cookieを自分のコンピューターに配置し、ハッキングされたコンピューターからCookieを削除することをどのように防ぐか。彼のコンピュータは、ハッキングされたコンピュータが知らなくても、必要に応じて認証および更新されますか?唯一の変更点は、ハッキングされたコンピューターユーザーが再度ログインして、覚えておく必要があることです。ハッキングされたユーザーがこれを認識しているかどうかは不明です。

24
@HiroProtagonistシリーズ識別子は、DoS攻撃を防ぐためのものです。それがなければ、すべてのユーザー名と無効なトークンでサイトを攻撃するスクリプトをすばやく作成し、サイトの全員をログアウトさせることができました。
Chris Moschini、2012年

6
この解決策は間違っており、通貨を処理しません。2つのremember-me認証要求が同時に到着し、同じremember-me cookieがある場合、最初の要求は成功してトークンを変更し、2番目の要求は認証に失敗します。誤報(トークンは最初の要求ですでに変更されているため)。(この状況は、ブラウザーの起動時に発生する可能性があり、サイトが2つのブラウザータブで復元されます。)
slobo

9

ユーザーIDとトークンを保存します。ユーザーがサイトに戻ってきたら、これら2つの情報を、データベースエントリのような永続的なものと比較します。

セキュリティに関しては、誰かがCookieを変更して追加の利益を得ることができるようなものをそこに置かないでください。たとえば、ユーザーグループやパスワードを保存しないでください。セキュリティを回避する変更可能なものは、Cookieに保存しないでください。


8

ユーザーIDとRememberMeTokenを保存します。彼らが私をチェックして覚えてログインすると、新しいRememberMeTokenが生成されます(これにより、マークされている他のすべてのマシンが無効になります)。

彼らが戻ってきたら、remember meトークンでそれらを調べ、UserIdが一致することを確認します。


これは、数秒でブルートフォースすることができます。user_idを1に設定し、すべてのトークンをブルートフォースにします。それは私に数秒でアクセスを与えます
友人

4

永続的なセッションを自分で調査するセキュリティのリスクに値するものではないことがわかりました。どうしても必要な場合に使用しますが、そのようなセッションは弱い認証のみを考慮し、攻撃者にとって価値のある可能性のあるすべてのものに対して新しいログインを強制する必要があります。

もちろん、永続的なセッションを含むCookieが簡単に盗まれるからです。

Cookieを盗む4つの方法(彼の回答に基づいたページでのJens Rolandのコメントから@splattne):

  1. 安全でない回線を介して傍受する(パケットスニッフィング/セッションハイジャック)
  2. ユーザーのブラウザに直接アクセスする(マルウェアまたはボックスへの物理的アクセスを介して)
  3. サーバーデータベースから読み取る(おそらくSQLインジェクションですが、何でもかまいません)
  4. XSSハック(または同様のクライアント側エクスプロイト)

104
1. HTTPSはこれを防ぐように設計されています。2.ログインしたままにすることは、ここでのセキュリティの問題ではなく、より大きな問題があります。3. 2と同じです。4。これは、アクセス制御ポリシーと適切な入力サニテーションによって防止できます。これらの手順を実行しないと、ログインしたままにするよりも大きな問題が発生します。
Chris Moschini、2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.