この Web アプリケーションには、uniqueid (64 ビットの int autoincrement フィールド、キー)、token (64 バイトのバイナリ フィールド)、および accountid の列を持つデータベース テーブルがあります。
「Remember Me」にチェックを入れてログインすると、ランダムなトークンが生成されます。次に、このトークンの SHA-512 ハッシュがデータベースに挿入され、生成された uniqueid が取得されます。uniqueid とハッシュされていないトークンを含む Cookie がクライアントに送信されます。
ユーザーが Cookie を含むページにアクセスするたびに、Cookie の uniqueid とそのトークンの SHA-512 ハッシュがデータベースに対してチェックされます。uniqueid に一致する行があり、その行のトークン ハッシュがトークン ハッシュと一致する場合は、行のアカウント ID を使用してユーザーをログインします。Cookie による認証試行ごとに、古い uniqueid を使用する行を削除し、認証が成功した場合は、新しいランダム トークンを生成します。次に、このトークンの SHA-512 ハッシュがデータベースに挿入され、生成された uniqueid が取得されます。uniqueid とハッシュされていないトークンを含む Cookie が、認証に成功したクライアントに送信されます。
ここで説明するテクニックも使用します。失敗したすべての Cookie 認証では、Cookie が空白の値に設定され、有効期限が過去のある時点に設定されます。
この方法は、Cookie に関するいくつかの問題に対処できると思います。すなわち:
データベース内のトークンはハッシュされるため、攻撃者はデータベースへの書き込みアクセス権を持っていない限り、すべてのユーザーの Cookie を偽造することはできません。
ログイン認証情報は Cookie に保存されないため、ユーザーのアカウント名の代わりに一意の ID が使用されます。
Cookie が認証されるたびにランダムなトークンが生成されるため、攻撃者が Cookie を盗んだ場合、ユーザーが記憶されている間ではなく、ユーザーが次にログインするまでのみ有効になります。
アプリケーション全体で HTTPS を使用しているため、Cookie を盗聴するのは困難です。
ユーザーが記憶したい期間を指定できるようにすることで、セキュリティをさらに強化できます。有効期限は、uniqueid とトークンを格納する同じデータベース テーブルに格納されます。新しい Cookie が作成されるたびに、この有効期限が Cookie と共に送信されます。サーバーが期限切れと見なした Cookie を使用してユーザーがログインしようとしたが、クライアントがまだ保持している場合、ログインは拒否されます。
このソリューションはかなり安全だと思いますが、この方法を設計したときに落とし穴や見落としたことはありますか?
ソース: