私のWebアプリケーションはセッションを使用して、ユーザーがログインした後のユーザーに関する情報を保存し、アプリ内のページ間を移動するときにその情報を維持します。この特定のアプリケーションでは、私が保管していますuser_id、first_nameそしてlast_name人の。
ログイン時に[ログイン状態を維持する]オプションを提供して、ユーザーのマシンにCookieを2週間保持し、ユーザーがアプリに戻ったときに同じ詳細でセッションを再開します。
これを行うための最良のアプローチは何ですか？user_idあるユーザーが別のユーザーのIDを偽造して簡単に偽造できるように思われるため、Cookieにそれらを保存したくありません。
回答:
わかりました、率直に言ってみましょう。ユーザーデータ、またはユーザーデータから派生したものをこの目的のためにCookieに入れている場合は、何か間違っています。
そこ。私はそれを言った。それでは、実際の答えに移りましょう。
ユーザーデータのハッシュの何が問題になっていますか？まあ、それは露出面とあいまいさによるセキュリティに帰着します。
あなたが攻撃者だと一瞬想像してみてください。セッションで、remember-meに設定された暗号化Cookieが表示されます。幅は32文字です。ああ。それはMD5かもしれません...
彼らがあなたが使ったアルゴリズムを知っていることを一瞬想像してみましょう。例えば：
md5(salt+username+ip+salt)これで、攻撃者が行う必要があるのは、「塩」をブルートフォースすることです（これは実際には塩ではありませんが、後で詳しく説明します）。IPアドレスのユーザー名を使用して、必要なすべての偽のトークンを生成できます。しかし、ブルートフォースをかけるのは難しいですよね？もちろんです。しかし、現代のGPUは非常に優れています。そして、その中で十分なランダム性を使用しない限り（十分に大きくする）、それはすぐに落下し、それに伴って城の鍵となります。
要するに、あなたを守る唯一のものはあなたが思っているほど実際にあなたを守っていない塩です。
ちょっと待って！
これらはすべて、攻撃者がアルゴリズムを知っていることを前提としています！それが秘密で混乱しているなら、あなたは安全ですよね？間違っています。その考え方には名前があります：Security Through Obscurity。これは決して信頼されるべきではありません。
より良い方法
より良い方法は、IDを除いて、ユーザーの情報がサーバーから出ないようにすることです。
ユーザーがログインするときに、大きな（128〜256ビット）ランダムトークンを生成します。これを、トークンをユーザーIDにマップするデータベーステーブルに追加し、Cookieでクライアントに送信します。
攻撃者が別のユーザーのランダムトークンを推測した場合はどうなりますか？
さて、ここで数学をしましょう。128ビットのランダムトークンを生成しています。つまり、
possibilities = 2^128
possibilities = 3.4 * 10^38
さて、その数がいかに驚くほど大きいかを示すために、インターネット上のすべてのサーバー（今日は50,000,000としましょう）がその数を毎秒1,000,000,000の割合でブルートフォースにしようとしているとしましょう。実際には、サーバーはそのような負荷の下で溶けるでしょうが、これを試してみましょう。
guesses_per_second = servers * guesses
guesses_per_second = 50,000,000 * 1,000,000,000
guesses_per_second = 50,000,000,000,000,000
つまり、1秒あたり50兆回の推測です。それは速いです！正しい？
time_to_guess = possibilities / guesses_per_second
time_to_guess = 3.4e38 / 50,000,000,000,000,000
time_to_guess = 6,800,000,000,000,000,000,000
6.8セクシオン秒...
それをもっと親しみやすい数字にしてみましょう。
215,626,585,489,599 yearsまたはさらに良い：
47917 times the age of the universeはい、それは宇宙の時代の47917倍です...
基本的に、それはクラックされないでしょう。
要約すると：
私が推奨するより良いアプローチは、3つの部分でCookieを保存することです。
function onLogin($user) {
$token = GenerateRandomToken(); // generate a token, should be 128 - 256 bit
storeTokenForUser($user, $token);
$cookie = $user . ':' . $token;
$mac = hash_hmac('sha256', $cookie, SECRET_KEY);
$cookie .= ':' . $mac;
setcookie('rememberme', $cookie);
}
次に、検証するには：
function rememberMe() {
$cookie = isset($_COOKIE['rememberme']) ? $_COOKIE['rememberme'] : '';
if ($cookie) {
list ($user, $token, $mac) = explode(':', $cookie);
if (!hash_equals(hash_hmac('sha256', $user . ':' . $token, SECRET_KEY), $mac)) {
return false;
}
$usertoken = fetchTokenByUserName($user);
if (hash_equals($usertoken, $token)) {
logUserIn($user);
}
}
}
注：トークンまたはユーザーとトークンの組み合わせを使用して、データベース内のレコードを検索しないでください。常にユーザーに基づいてレコードをフェッチし、タイミングセーフな比較関数を使用して、フェッチしたトークンを後で比較するようにしてください。タイミング攻撃の詳細。
さて、それが暗号の秘密であることは非常に重要ですSECRET_KEY（/dev/urandom高エントロピー入力のようなものによって生成された、および/または高エントロピー入力から派生した）。また、GenerateRandomToken()強力なランダムソースである必要があります（mt_rand()十分に強力ではありません。RandomLibやrandom_compatなどのライブラリを使用するかmcrypt_create_iv()、DEV_URANDOM）で...
hash_equals()ないようにすることであるタイミング攻撃を。PHP 5.6より前のバージョンのPHPを使用する場合、この機能hash_equals()はサポートされません。この場合hash_equals()、timingSafeCompare関数で置き換えることができます。
/**
* A timing safe equals comparison
*
* To prevent leaking length information, it is important
* that user input is always used as the second parameter.
*
* @param string $safe The internal (safe) value to be checked
* @param string $user The user submitted (unsafe) value
*
* @return boolean True if the two strings are identical.
*/
function timingSafeCompare($safe, $user) {
if (function_exists('hash_equals')) {
return hash_equals($safe, $user); // PHP 5.6
}
// Prevent issues if string length is 0
$safe .= chr(0);
$user .= chr(0);
// mbstring.func_overload can make strlen() return invalid numbers
// when operating on raw binary strings; force an 8bit charset here:
if (function_exists('mb_strlen')) {
$safeLen = mb_strlen($safe, '8bit');
$userLen = mb_strlen($user, '8bit');
} else {
$safeLen = strlen($safe);
$userLen = strlen($user);
}
// Set the result to the difference between the lengths
$result = $safeLen - $userLen;
// Note that we ALWAYS iterate over the user-supplied length
// This is to prevent leaking length information
for ($i = 0; $i < $userLen; $i++) {
// Using % here is a trick to prevent notices
// It's safe, since if the lengths are different
// $result is already non-0
$result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i]));
}
// They are only identical strings if $result is exactly 0...
return $result === 0;
}
セキュリティに関する通知：確定的データのMD5ハッシュに基づいてCookieを作成することはお勧めできません。CSPRNGから派生したランダムトークンを使用することをお勧めします。より安全なアプローチについては、この質問に対するircmaxellの回答を参照してください。
通常、私はこのようなことをします：
もちろん、異なるCookie名などを使用することもできます。また、Cookieの内容を少し変更することもできます。簡単に作成されないようにしてください。たとえば、ユーザーの作成時にuser_saltを作成し、それをCookieに置くこともできます。
また、md5（またはほとんどすべてのアルゴリズム）の代わりにsha1を使用することもできます。
前書き
あなたのタイトル「Keep Me Logged In」-最善のアプローチでは、どこから始めればよいかわからなくなります。最善のアプローチを検討している場合、次のことを考慮する必要があるためです。
クッキー
Cookieは脆弱です。一般的なブラウザーのCookie盗難の脆弱性とクロスサイトスクリプティング攻撃の間で、Cookieは安全ではないことを受け入れる必要があります。セキュリティを向上させるにphp setcookiesは、次のような追加機能があることに注意する必要があります
bool setcookie（string $ name [、string $ value [、int $ expire = 0 [、string $ path [、string $ domain [、bool $ secure = false [、bool $ httponly = false]]]]]]）
定義
シンプルなアプローチ
簡単な解決策は次のとおりです。
上記のケーススタディは、このページに示されているすべての例を要約していますが、欠点は
より良いソリューション
より良い解決策は
コード例
// Set privateKey
// This should be saved securely
$key = 'fc4d57ed55a78de1a7b31e711866ef5a2848442349f52cd470008f6d30d47282';
$key = pack("H*", $key); // They key is used in binary form
// Am Using Memecahe as Sample Database
$db = new Memcache();
$db->addserver("127.0.0.1");
try {
// Start Remember Me
$rememberMe = new RememberMe($key);
$rememberMe->setDB($db); // set example database
// Check if remember me is present
if ($data = $rememberMe->auth()) {
printf("Returning User %s\n", $data['user']);
// Limit Acces Level
// Disable Change of password and private information etc
} else {
// Sample user
$user = "baba";
// Do normal login
$rememberMe->remember($user);
printf("New Account %s\n", $user);
}
} catch (Exception $e) {
printf("#Error %s\n", $e->getMessage());
}使用するクラス
class RememberMe {
private $key = null;
private $db;
function __construct($privatekey) {
$this->key = $privatekey;
}
public function setDB($db) {
$this->db = $db;
}
public function auth() {
// Check if remeber me cookie is present
if (! isset($_COOKIE["auto"]) || empty($_COOKIE["auto"])) {
return false;
}
// Decode cookie value
if (! $cookie = @json_decode($_COOKIE["auto"], true)) {
return false;
}
// Check all parameters
if (! (isset($cookie['user']) || isset($cookie['token']) || isset($cookie['signature']))) {
return false;
}
$var = $cookie['user'] . $cookie['token'];
// Check Signature
if (! $this->verify($var, $cookie['signature'])) {
throw new Exception("Cokies has been tampared with");
}
// Check Database
$info = $this->db->get($cookie['user']);
if (! $info) {
return false; // User must have deleted accout
}
// Check User Data
if (! $info = json_decode($info, true)) {
throw new Exception("User Data corrupted");
}
// Verify Token
if ($info['token'] !== $cookie['token']) {
throw new Exception("System Hijacked or User use another browser");
}
/**
* Important
* To make sure the cookie is always change
* reset the Token information
*/
$this->remember($info['user']);
return $info;
}
public function remember($user) {
$cookie = [
"user" => $user,
"token" => $this->getRand(64),
"signature" => null
];
$cookie['signature'] = $this->hash($cookie['user'] . $cookie['token']);
$encoded = json_encode($cookie);
// Add User to database
$this->db->set($user, $encoded);
/**
* Set Cookies
* In production enviroment Use
* setcookie("auto", $encoded, time() + $expiration, "/~root/",
* "example.com", 1, 1);
*/
setcookie("auto", $encoded); // Sample
}
public function verify($data, $hash) {
$rand = substr($hash, 0, 4);
return $this->hash($data, $rand) === $hash;
}
private function hash($value, $rand = null) {
$rand = $rand === null ? $this->getRand(4) : $rand;
return $rand . bin2hex(hash_hmac('sha256', $value . $rand, $this->key, true));
}
private function getRand($length) {
switch (true) {
case function_exists("mcrypt_create_iv") :
$r = mcrypt_create_iv($length, MCRYPT_DEV_URANDOM);
break;
case function_exists("openssl_random_pseudo_bytes") :
$r = openssl_random_pseudo_bytes($length);
break;
case is_readable('/dev/urandom') : // deceze
$r = file_get_contents('/dev/urandom', false, null, 0, $length);
break;
default :
$i = 0;
$r = "";
while($i ++ < $length) {
$r .= chr(mt_rand(0, 255));
}
break;
}
return substr(bin2hex($r), 0, $length);
}
}FirefoxとChromeでのテスト
利点
不利益
クイックフィックス
複数のCookieアプローチ
攻撃者がCookieを盗もうとするとき、特定のWebサイトやドメインなどにのみそれを集中させます。example.com
しかし、実際には2つの異なるドメイン（example.com＆fakeaddsite.com）のユーザーを認証して、「広告Cookie」のようにすることができます。
一部の人々は、2つの異なるCookieをどのように使用できるのか疑問に思うかもしれません。まあ想像し、その可能性example.com = localhostとfakeaddsite.com = 192.168.1.120。クッキーを調べると次のようになります
上の画像から
192.168.1.120
HTTP_REFERERREMOTE_ADDR利点
不利益
改善
ajax 古いスレッドですが、まだ問題があります。私はセキュリティに関していくつかの良い反応に気づき、「あいまいさによるセキュリティ」の使用を避けましたが、与えられた実際の技術的方法は私の目には十分ではありませんでした。私の方法を提供する前に私が言わなければならないこと：
つまり、システムに自動サインインするには2つの方法があります。
まず、それをすべて他の人に任せる安価で簡単な方法。たとえば、Google +アカウントを使用してサイトサポートのログインを作成した場合、ユーザーが既にGoogleにサインインしている場合にユーザーをログインするための合理化されたgoogle +ボタンがあるはずです（私はいつもここにいるので、この質問に答えるためにここにグーグルにサインイン）。ユーザーが信頼できるサポートされている認証システムで既にサインインしていて、そのためのチェックボックスをオンにした場合、ユーザーが自動的にサインインするようにするには、ロードする前にクライアント側のスクリプトに対応する「サインイン」ボタンの背後にあるコードを実行させる、ユーザーに使用するユーザー名、セッションID、認証システムを含む自動サインインテーブルに一意のIDをサーバーに保存するようにしてください。これらのサインインメソッドはAJAXを使用しているため、とにかく応答を待っています。その応答は、検証済みの応答または拒否のいずれかです。検証された応答を受け取った場合は、それを通常どおりに使用してから、ログインしたユーザーを通常どおりにロードし続けます。それ以外の場合、ログインは失敗しましたが、ユーザーに通知せず、ログインしていないとして続行すると、ユーザーに通知されます。これは、Cookieを盗んだ（または特権を昇格させるために偽造した）攻撃者が、ユーザーがサイトに自動サインインしたことを知らないようにするためです。
これは安価であり、すでにサインインしている可能性のあるユーザーを、GoogleやFacebookなどの場所で、通知することなく検証しようとするため、ダーティだと見なされることもあります。ただし、サイトの自動サインインを要求していないユーザーには使用しないでください。この特定の方法は、Google +やFBなどの外部認証専用です。
外部認証システムを使用して、ユーザーが検証されたかどうかを裏側のサーバーに通知するため、攻撃者は、それ自体では役に立たない一意のID以外のものを取得できません。詳しく説明します。
たとえ攻撃者が存在しないIDを使用したとしても、検証された応答が受信された場合を除いて、すべての試行で失敗するはずです。
この方法は、外部認証システムを使用してサイトにサインインする人のために、内部認証システムと組み合わせて使用できます。
=========
これで、ユーザーを自動サインインできる独自の認証システムの場合、次のようになります。
DBにはいくつかのテーブルがあります。
TABLE users:
UID - auto increment, PK
username - varchar(255), unique, indexed, NOT NULL
password_hash - varchar(255), NOT NULL
...ユーザー名は255文字まで可能です。サーバープログラムでシステムのユーザー名を32文字に制限していますが、外部認証システムでは@ domain.tldのユーザー名がそれよりも大きい場合があるため、互換性を最大にするためにメールアドレスの最大長をサポートしています。
TABLE sessions:
session_id - varchar(?), PK
session_token - varchar(?), NOT NULL
session_data - MediumText, NOT NULLログインしたときのユーザー名はセッションデータにあり、プログラムはnullデータを許可しないため、このテーブルにはユーザーフィールドがないことに注意してください。session_idとsession_tokenは、ランダムなmd5ハッシュ、sha1 / 128/256ハッシュ、ランダムな文字列が追加されたハッシュされた日時スタンプ、または好きなものを使用して生成できますが、出力のエントロピーは許容できる限り高くする必要がありますブルートフォース攻撃が地面から離れるのを軽減し、セッションクラスによって生成されたすべてのハッシュを追加する前に、セッションテーブルで一致するかどうかを確認する必要があります。
TABLE autologin:
UID - auto increment, PK
username - varchar(255), NOT NULL, allow duplicates
hostname - varchar(255), NOT NULL, allow duplicates
mac_address - char(23), NOT NULL, unique
token - varchar(?), NOT NULL, allow duplicates
expires - datetime codeMACアドレスはその性質上、一意であることが想定されているため、各エントリが一意の値を持つことは理にかなっています。一方、ホスト名は別のネットワーク上で正当に複製される可能性があります。「Home-PC」をコンピュータ名の1つとして使用している人はどれくらいいますか？ユーザー名はサーバーバックエンドによってセッションデータから取得されるため、操作することはできません。トークンについては、ページのセッショントークンを生成する同じ方法を使用して、ユーザーの自動サインイン用のCookieにトークンを生成する必要があります。最後に、ユーザーが資格情報を再検証する必要がある場合の日時コードが追加されます。ユーザーのログイン時にこの日時を更新して数日以内に維持するか、最後のログインに関係なく、強制的に1か月間だけ維持するように設計の指示に従って強制的に期限切れにします。
体系的に彼らが自動兆候を知っているユーザーのためのMACとホスト名をスプーフィングからこれを防止する誰か。NEVERユーザーにパスワード、クリアテキスト、またはその他の方法でCookieを保持してもらいます。セッショントークンの場合と同じように、各ページナビゲーションでトークンを再生成します。これにより、攻撃者が有効なトークンCookieを取得してログインに使用する可能性が大幅に減少します。一部の人々は、攻撃者が被害者からCookieを盗み、セッション再生攻撃を行ってログインする可能性があると述べようとします。攻撃者がCookieを盗む（これが可能である）場合、デバイス全体を危険にさらす可能性があります。つまり、デバイスを使用してログインするだけで、Cookieを盗む目的を完全に失う可能性があります。サイトがHTTPS（パスワード、CC番号、またはその他のログインシステムを処理する場合）で実行されている限り、ブラウザー内で可能なすべての保護をユーザーに提供しています。
注意すべき点の1つは、自動サインインを使用する場合、セッションデータが期限切れにならないようにすることです。セッションを誤って継続する機能を期限切れにすることができますが、システム間で検証すると、セッションデータがセッション間で継続すると予想される永続的なデータである場合は、セッションデータを再開する必要があります。永続セッションデータと非永続セッションデータの両方が必要な場合は、ユーザー名をPKとして永続セッションデータ用の別のテーブルを使用し、通常のセッションデータと同じようにサーバーにデータを取得させます。別の変数を使用します。
この方法でログインが完了すると、サーバーはセッションを検証する必要があります。これは、盗難または侵害されたシステムに対する期待をコード化できる場所です。セッションデータへのログインのパターンやその他の予期される結果は、アクセスを獲得するためにシステムがハイジャックされた、またはCookieが偽造されたという結論につながることがよくあります。これは、ISS Techが、アカウントのロックダウンまたは自動サインインシステムからのユーザーの自動削除をトリガーするルールを設定できる場所であり、ユーザーが攻撃者を成功させる方法とその方法を判断するのに十分な時間、攻撃者を締め出します。
最後に、回復の試み、パスワードの変更、またはログインの失敗がしきい値を超えた場合は、ユーザーが適切に検証してこれが発生したことを確認するまで、自動サインインが無効になることを確認してください。
誰かが私の回答でコードが渡されることを期待していた場合は謝罪します。それはここでは起こりません。私はPHP、jQuery、およびAJAXを使用してサイトを実行し、Windowsをサーバーとして使用することはありません。
Stefanが述べたアプローチを推奨します（つまり、永続的ログインCookieのベストプラクティスのガイドラインに従ってください）。また、CookieがHttpOnly Cookieであることを確認して、JavaScriptにアクセスできないようにすることをお勧めします。
おそらくあなただけが知っている秘密でハッシュを生成し、それをDBに保存して、ユーザーに関連付けられるようにします。かなりうまくいくはずです。
私の解決策はこのようなものです。100％防弾というわけではありませんが、ほとんどの場合であなたを救うと思います。
ユーザーが正常にログインすると、次の情報を含む文字列が作成されます。
$data = (SALT + ":" + hash(User Agent) + ":" + username
+ ":" + LoginTimestamp + ":"+ SALT)暗号化し$data、タイプをHttpOnlyに設定し、Cookieを設定します。
ユーザーがサイトに戻ってきたら、次の手順を実行します。
:キャラクターで爆発させます。ユーザーがログアウトする場合は、このCookieを削除してください。ユーザーが再ログインする場合は、新しいCookieを作成します。
暗号化されたものをハッキングする必要があるのが暗号化されたバージョンである場合、暗号化されたものをCookieに保存するという概念は理解できません。何か足りない場合はコメントしてください。
私はこのアプローチを 'Remember Me'に取り入れることを考えています。問題があればコメントしてください。
複数のデバイスからログインできるように、ユーザーテーブルとは別に、「Remember Me」データを格納するテーブルを作成します。
ログイン成功時（Remember Meがチェックされている場合）：
a）このマシンのUserIDとして使用される一意のランダム文字列を生成します：bigUserID
b）一意のランダム文字列を生成します：bigKey
c）Cookieを保存します：bigUserID：bigKey
d）[Remember Me]テーブルに、UserID、IPアドレス、bigUserID、bigKeyを含むレコードを追加します
ログインが必要なものにアクセスしようとする場合：
a）Cookieを確認し、一致するIPアドレスでbigUserIDとbigKeyを検索します
b）見つかった場合は、ログインしますが、ユーザーテーブルに「ソフトログイン」のフラグを設定して、危険な操作があった場合に完全なログインを要求できるようにします。
ログアウト時に、そのユーザーのすべての「Remember Me」レコードに期限切れのマークを付けます。
私が見ることができる唯一の脆弱性は、
私はすべての答えを読みましたが、それでも自分のやるべきことを抽出するのは困難でした。写真が1,000ワードに相当する場合、これが他のユーザーがバリージャスパンの改良された永続的ログインCookieのベストプラクティスに基づく安全な永続的ストレージの実装に役立つことを願っています
質問、フィードバック、または提案がある場合は、図を更新して、安全な永続的ログインを実装しようとしている初心者に反映させます。
「ログイン状態を維持」機能を実装するには、ユーザーにとっての意味を正確に定義する必要があります。最も単純なケースでは、これを使用して、セッションのタイムアウトがはるかに長くなることを意味します。たとえば、2時間ではなく2日です。これを行うには、おそらくデータベース内に独自のセッションストレージが必要になるため、セッションデータのカスタム有効期限を設定できます。次に、ブラウザを閉じたときに期限切れになるのではなく、数日（またはそれ以上）固定されるCookieを設定する必要があります。
「なぜ2日間なのか、なぜ2週間なのか」という質問を聞くことができます。これは、PHPでセッションを使用すると、有効期限が自動的に押し戻されるためです。これは、PHPでのセッションの有効期限が実際にはアイドルタイムアウトであるためです。
そうは言っても、おそらく、セッション自体に格納し、2週間程度で出力する、より難しいタイムアウト値を実装し、それを確認してセッションを強制的に無効にするコードを追加します。または、少なくともログアウトします。これは、ユーザーが定期的にログインするように求められることを意味します。Yahoo! これを行います。
私はあなたがこれを行うことができると思います：
$cookieString = password_hash($username, PASSWORD_DEFAULT);お店 $cookiestring DB内とし、クッキーとして設定します。また、そのユーザーのユーザー名をCookieとして設定します。ハッシュの要点は、リバースエンジニアリングできないことです。
ユーザーが現れたら、$cookieString別のCookieからではなく、1つのCookieからユーザー名を取得します。$cookieStringDBに保存されているものと一致する場合、ユーザーは認証されます。password_hashは毎回異なるソルトを使用するため、クリアテキストが何であるかは関係ありません。