"Keep Me Logged In" - лучший подход

мое веб-приложение использует сеансы для хранения информации о пользователе после того, как они вошли в систему, и для поддержания этой информации, когда они перемещаются со страницы на страницу в приложении. В этом конкретном приложении я сохраняю user_id,first_name и last_name человека.

Я хотел бы предложить опцию "Keep Me Logged In" при входе в систему, которая будет помещать cookie на машину пользователя в течение двух недель, что перезапустит их сеанс с теми же деталями, когда они вернутся к приложение.

каков наилучший подход для этого? Я не хочу хранить их user_id в файле cookie, поскольку кажется, что это облегчит одному пользователю попытку подделать личность другого пользователя.

12 220
php security session remember-me

12 ответов:

хорошо, позвольте мне прямо сказать: если вы помещаете пользовательские данные или что-либо, полученное из пользовательских данных, в cookie для этой цели, вы делаете что-то неправильно.

там. Я так и сказал. Теперь мы можем перейти к фактическому ответу.

что не так с хэшированием пользовательских данных, спросите вы? Ну, это сводится к поверхности воздействия и безопасности через неизвестность.

представьте на секунду, что вы нападающий. Вы видите криптографический набор файлов cookie для помните-я на вашем сеансе. Это 32 символов в ширину. Джи. Это может быть MD5...

давайте представим на секунду, что они знают алгоритм, который вы использовали. Например: 
md5(salt+username+ip+salt)

теперь все, что нужно сделать злоумышленнику, это грубая сила "соли" (которая на самом деле не соль, но об этом позже), и теперь он может генерировать все поддельные токены, которые он хочет с любым именем пользователя для своего IP-адреса! Но грубое принуждение соли трудно, не так ли? Абсолютно. Но современные графические процессоры-это чрезвычайно хорош в этом. И если вы не используете достаточную случайность в нем (сделайте его достаточно большим), он быстро упадет, а вместе с ним и ключи от вашего замка.

Но Подождите!

все это было основано на том, что злоумышленник знает алгоритм! Если это секретно и запутанно, то ты в безопасности, верно? неправильно. Эта линия мышления имеет название:Безопасность Через Незаметность, который должен никогда было положиться.

Лучше

лучший способ-никогда не позволять информации пользователя покидать сервер, за исключением идентификатора.

когда пользователь входит в систему, генерируйте большой (от 128 до 256 бит) случайный маркер. Добавьте это в таблицу базы данных, которая сопоставляет маркер с идентификатором пользователя, а затем отправьте его в клиента в cookie.

что делать, если злоумышленник угадывает случайный токен другого пользователя?

ну, давайте сделаем некоторые математические здесь. Мы генерируем 128-битный случайный токен. Это означает, что есть:

possibilities = 2^128
possibilities = 3.4 * 10^38

guesses_per_second = servers * guesses
guesses_per_second = 50,000,000 * 1,000,000,000
guesses_per_second = 50,000,000,000,000,000

так что 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 раз больше возраста Вселенной...

в принципе, он не будет взломан.

подведем итог:

в лучший подход, который я рекомендую, это хранить куки с тремя частями. 

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)...

The hash_equals() для предотвращения сроки нападения. Если вы используете версию PHP ниже PHP 5.6 функция 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;
}
627

Примечание: основывать cookie на хэше MD5 детерминированных данных-плохая идея; лучше использовать случайный токен, полученный из CSPRNG. Смотрите ircmaxell это!--5--> к этому вопросу для более безопасного подхода.

обычно я делаю что-то вроде этого:

  1. пользователь входит в систему с помощью "keep me logged in"
  2. создать сессию
  3. создать файл cookie под названием Что-то содержащее: md5 (salt + username+ip+salt) и cookie под названием somethingElse, содержащий id
  4. хранить cookie в базе данных
  5. пользователь делает вещи и уходит ----
  6. пользователь возвращает, проверяет для somethingElse cookie, если он существует, получить старый хэш из базы данных для этого пользователя, проверить содержимое cookie что-то совпадение с хэшем из базы данных, которая также должна совпадать с вновь вычисленным хэшем (для ip) таким образом: cookieHash= = databaseHash= = md5 (соль+имя пользователя+ip + соль), если они делают, Гото 2, если они не Гото 1

конечно, вы можете использовать разные имена файлов cookie и т. д. также вы можете немного изменить содержимое файла cookie, просто убедитесь, что он не легко создается. Например, вы можете также создать user_salt при создании пользователя, а также поместить его в файл cookie.

также вы можете использовать sha1 вместо md5 (или почти любой алгоритм)

94

введение

ваш заголовок "держите меня в системе" - лучший подход сделать это трудно для меня, чтобы знать, с чего начать, потому что если вы ищете лучший подход, то вам придется рассмотреть следующее :

  • идентификация
  • безопасность

Cookies

Cookies уязвимы, между общими уязвимостями cookie-кражи браузера и межсайтовые скриптовые атаки мы должны признать, что куки-файлы небезопасны. Чтобы помочь улучшить безопасность, вы должны отметить, что phpsetcookies имеет дополнительную функциональность, такую как

буль setcookie (string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $ secure = false [, bool $httponly = false ]]]]]])

  • безопасный (с помощью HTTPS соединение)
  • httponly (уменьшить кражу личных данных через XSS атаки)

определения

  • токен (непредсказуемая случайная строка длиной n например. /dev / urandom)
  • ссылка (непредсказуемая случайная строка длиной n например. /dev / urandom)
  • подпись (сгенерируйте хэш-значение с ключом, используя метод HMAC)

Простой Подход

простой решение было бы:

  • пользователь вошел в систему с Remember Me
  • логин Cookie выдается с токеном и подписью
  • когда возвращается, подпись проверяется
  • если подпись в порядке .. затем имя пользователя и токен в базе данных
  • если не действует .. вернуться на страницу входа
  • если действителен автоматический вход

выше примере приведены все примеры, приведенные на этой странице, но они недостатки в том, что

  • нет никакого способа узнать, если печенье было украдено
  • злоумышленник может получить доступ к конфиденциальной операции, такие как изменение пароля или данных, таких как личные и запекания информации и т. д.
  • зараженные файлы, которые по-прежнему будут действительны на срок жизни куки

Лучшим Решением

лучшим решением было бы

  • пользователь вошел в систему и Запомнить меня выбрано
  • создать маркер и подпись и хранить в cookie
  • маркеры являются случайными и действительны только для одной аутентификации
  • токен заменяется при каждом посещении сайта
  • когда незарегистрированный пользователь посещает сайт, подпись, токен и имя пользователя проверяются
  • Запомнить меня логин должен иметь ограниченный доступ и не допускать изменения пароля, личной информации так далее.

Пример Кода

// 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());
}

67

есть две очень интересные статьи, которые я нашел во время поиска идеального решения для проблемы "Запомнить меня":

24

Я задал один угол этого вопроса здесь, и ответы приведут вас ко всем ссылкам cookie на основе маркеров, которые вам нужны.

в принципе, вы не храните идентификатор пользователя в cookie. Вы храните одноразовый токен (огромная Строка), который пользователь использует для получения своего старого сеанса входа в систему. Затем, чтобы сделать его действительно безопасным, вы просите пароль для тяжелых операций (например, изменение самого пароля).

6

Я бы рекомендовал подход, упомянутый Стефаном (т. е. следовать рекомендациям в Улучшена Постоянная Практика Входа В Cookie), а также рекомендуем вам убедиться, что ваши печенье HttpOnly cookies таким образом, они не доступны для потенциально вредоносного JavaScript.

5

создайте хэш, возможно, с секретом, который только вы знаете, а затем сохраните его в своей БД, чтобы он мог быть связан с пользователем. Должно работать достаточно хорошо.

4

старый поток, но все еще действительная забота. Я заметил некоторые хорошие ответы о безопасности и избегал использования "безопасности через неясность", но фактические технические методы, приведенные в моих глазах, были недостаточными. Вещи, которые я должен сказать, прежде чем внести свой метод:

  • никогда хранить пароль в открытом виде...Никогда!
  • никогда хранить хэшированный пароль пользователя в нескольких местах в базе данных. Ваш сервер бэкэнд всегда способный вытягивать хэшированный пароль из таблицы пользователей. Не более эффективно хранить избыточные данные вместо дополнительных транзакций БД, обратное верно.
  • Ваш идентификатор сеанса должен быть уникальным, поэтому никакие два пользователя не могут когда-нибудь поделитесь идентификатором, следовательно, целью идентификатора (может ли ваш идентификационный номер водительских прав когда-либо соответствовать другим лицам? Нет.) Это создает уникальную комбинацию из двух частей, основанную на 2 уникальных строках. Ваша таблица сеансов должна использовать идентификатор в качестве ПК. Чтобы разрешить нескольким устройствам быть доверенными для автоматической регистрации, используйте другую таблицу для доверенных устройств, которая содержит список всех проверенных устройств (см. мой пример ниже) и сопоставляется с использованием имени пользователя.
  • он не служит для хэширования известных данных в файл cookie, файл cookie может быть скопирован. Что мы ищем в выполнении пользовательского устройства, чтобы обеспечить достоверность информации, которая не может быть получена без злоумышленника в машине пользователя (опять же, см. мой пример). Это однако это означает, что законный пользователь, который запрещает статическую информацию своей машины (т. е. MAC-адрес, имя хоста устройства, агент пользователя, если он ограничен браузером и т. д.) из оставшихся последовательными (или подделывает его в первую очередь) не сможет использовать эту функцию. Но если это вызывает беспокойство, учтите тот факт, что вы предлагаете авто-вход для пользователей, которые идентифицируют себя однозначно, поэтому, если они отказываются быть известными путем подмены их MAC, подмены их useragent, спуфинг / изменение имени хоста, скрытие за прокси и т. д., то они не идентифицируются, и никогда не должны быть аутентифицированы для автоматического обслуживания. Если вы хотите этого, вам нужно изучить доступ к смарт-карте в комплекте с клиентским программным обеспечением, которое устанавливает личность для используемого устройства.

Это все, как говорится, есть два отличных способа, чтобы иметь авто-вход в вашей системе.

во-первых, дешевый, простой способ, который ставит все это на кого-то другого. Если вы сделаете поддержка вашего сайта вход в систему с помощью, скажем, вашей учетной записи google+, у вас, вероятно, есть оптимизированная кнопка google+, которая войдет в систему пользователя, если они уже вошли в google (я сделал это здесь, чтобы ответить на этот вопрос, так как я всегда входил в google). Если вы хотите, чтобы пользователь автоматически вошел в систему, если он уже вошел в систему с помощью надежного и поддерживаемого средства проверки подлинности, и установил флажок для этого, попросите ваши клиентские сценарии выполнить код за соответствующей кнопкой " вход с помощью перед загрузкой просто убедитесь, что сервер хранит уникальный идентификатор в таблице автоматической регистрации, которая имеет имя пользователя, идентификатор сеанса и Аутентификатор, используемый для пользователя. Поскольку эти методы входа используют AJAX, вы все равно ждете ответа, и этот ответ является либо проверенным ответом, либо отклонением. Если вы получили проверенный ответ, используйте его как обычно, а затем продолжите загрузку зарегистрированного пользователя как обычно. В противном случае вход не удался, но не говорите пользователю, просто продолжайте, как не вошли в систему, они заметят. Это делается для того, чтобы злоумышленник, который украл файлы cookie (или подделал их в попытке повысить привилегии), не узнал, что пользователь автоматически входит на сайт.

это дешево, а также может считаться грязным некоторыми, потому что он пытается проверить ваш потенциально уже подписанный в себя с такими местами, как Google и Facebook, даже не говоря вам. Однако он не должен использоваться для пользователей, которые не просили авто-входа на ваш сайт, и этот конкретный метод только для внешней аутентификации, как с Google+ или FB.

поскольку внешний Аутентификатор использовался для того, чтобы сообщить серверу за кулисами, был ли проверен пользователь, злоумышленник не может получить ничего, кроме уникального идентификатора, который сам по себе бесполезен. Я уточню:

  • пользователь ' joe ' посещает сайт в первый раз, идентификатор сеанса помещается в cookie 'session'.
  • пользователь ' joe ' входит в систему, увеличивает привилегии, получает новый идентификатор сеанса и обновляет cookie "сеанс".
  • пользователь ' joe ' выбирает автоматическую регистрацию с помощью google+, получает уникальный идентификатор, помещенный в cookie 'keepmesignedin'.
  • пользователь " Джо " имеет google держать их вошли в систему, что позволяет ваш сайт для автоматической регистрации Пользователя с помощью google в вашем бэкэнде.
  • злоумышленник систематически пытается использовать уникальные идентификаторы для "keepmesignedin" (это общедоступное знание, выдаваемое каждому пользователю) и не входит ни в какое другое место; пытается использовать уникальный идентификатор, заданный "Джо".
  • сервер получает уникальный ID для "Джо", тянет матч в БД для учетной записи google+.
  • сервер отправляет злоумышленника на страницу входа, которая запускает запрос AJAX в google для входа.
  • сервер Google получает запрос, использует свой API, чтобы увидеть, что злоумышленник не вошел в систему в настоящее время.
  • Google отправляет ответ, что в настоящее время нет подписанного пользователя по этому соединению.
  • страница злоумышленника получает ответ, скрипт автоматически перенаправляет на страницу входа со значением POST, закодированным в url-адрес.
  • страница входа получает значение POST, отправляет файл cookie для "keepmesignedin" в пустое значение и действительное до даты 1-1-1970, чтобы предотвратить автоматическую попытку, в результате чего браузер злоумышленника просто удалит файл cookie.
  • злоумышленник получает нормальную страницу входа в первый раз.

независимо от того, что, даже если злоумышленник использует идентификатор, который не существует, попытка должна завершиться неудачей на всех попытках, за исключением случаев, когда проверенный ответ полученный.

этот метод может и должен использоваться совместно с вашим внутренним аутентификатором для тех, кто входит на ваш сайт с помощью внешнего аутентификатора.

=========

Теперь, для вашей собственной системы аутентификации, которая может автоматически подписывать пользователей, вот как я это делаю:

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

обратите внимание, что в этой таблице нет поля пользователя, потому что имя пользователя при входе в систему находится в данных сеанса, и программа не разрешает нулевые данные. Session_id и session_token могут быть сгенерированы с использованием случайных md5 хэшей, sha1 / 128 / 256 хэшей, метки datetime со случайными строками, добавленными к ним, затем хэшируются или что бы вы ни хотели, но энтропия вашего вывода должна оставаться настолько высокой, насколько это допустимо, чтобы смягчить атаки грубой силы даже от отрыва от Земли, и все хэши, созданные вашим классом сеанса, должны быть проверены на соответствие в таблице сеансов до попытки их добавления.

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 code

MAC-адреса по своей природе должны быть уникальными, поэтому имеет смысл, что каждая запись имеет уникальный значение. С другой стороны, имена хостов могут быть законно продублированы в отдельных сетях. Сколько людей используют "домашний ПК" в качестве одного из своих имен компьютеров? Имя пользователя берется из данных сеанса серверной частью, поэтому манипулировать им невозможно. Что касается токена, то тот же метод генерации токенов сеанса для страниц должен использоваться для генерации токенов в файлах cookie для автоматической регистрации пользователя. Наконец, код datetime добавляется для тех случаев, когда пользователю потребуется повторно проверить свои учетные данные. Либо обновите этот datetime при входе пользователя в систему, сохраняя его в течение нескольких дней, либо заставьте его истекать независимо от последнего входа в систему, сохраняя его только в течение месяца или около того, в зависимости от вашего дизайна.

это предотвращает кого-то от систематического подмены MAC и имя хоста для пользователя, которого они знают авто-вход. никогда пусть пользователь сохранит файл cookie со своим паролем, открытым текстом или иным образом. Пусть маркер будет восстановлен на каждой странице навигации, так же, как и вы токен сеанса. Это значительно снижает вероятность того, что злоумышленник может получить действительный печенье маркер и использовать его для входа в систему. Некоторые люди попытаются сказать, что злоумышленник может украсть куки-файлы у жертвы и сделать атаку повтора сеанса для входа в систему. Если бы злоумышленник мог украсть куки (что возможно), они, безусловно, скомпрометировали бы все устройство, то есть они могли бы просто использовать устройство для входа в систему в любом случае, что полностью уничтожает цель кражи куки. Пока ваш сайт работает по протоколу HTTPS (который он должен иметь дело с паролями, номерами CC или другими системами входа в систему), вы предоставили всю защиту пользователю, которую вы можете в браузере.

одна вещь, чтобы иметь в виду: данные сеанса не должны истекать, если вы используете автоматическую регистрацию. Вы можете истечь возможность продолжить сеанс ложно, но проверка в системе должна возобновить данные сеанса, если это постоянные данные, которые, как ожидается, будут продолжаться между сеансами. Если вы хотите постоянные и непостоянные данные сеанса, используйте другую таблицу для постоянных данных сеанса с именем пользователя в качестве PK и попросите сервер получить его, как и обычные данные сеанса, просто используйте другую переменную.

после того, как логин был достигнут таким образом, сервер все равно должен проверить сеанс. Здесь можно закодировать ожидания для украденных или скомпрометированных систем; шаблоны и другие ожидаемые результаты входа в данные сеанса часто могут привести к выводам, что a система была захвачена или куки были подделаны для того, чтобы получить доступ. Здесь ваша технология ISS может поместить правила, которые вызовут блокировку учетной записи или автоматическое удаление пользователя из системы автоматической регистрации, удерживая злоумышленников достаточно долго, чтобы пользователь мог определить, как злоумышленник преуспел и как их отключить.

в качестве заключительной заметки убедитесь, что любая попытка восстановления, изменения пароля или сбои входа за порогом приводят к отключению автоматической регистрации до тех пор, пока пользователь проверяет должным образом и подтверждает, что это произошло.

Я извиняюсь, если кто-то ожидал, что код будет выдан в моем ответе, это не произойдет здесь. Я скажу, что я использую PHP, jQuery и AJAX для запуска моих сайтов, и я никогда не использую Windows в качестве сервера... когда-либо.

3

мое решение такое. Это не 100% пуленепробиваемый, но я думаю, что это спасет вас в большинстве случаев.

когда пользователь вошел в систему успешно создать строку с этой информацией:

$data = (SALT + ":" + hash(User Agent) + ":" + username 
                     + ":" + LoginTimestamp + ":"+ SALT)

шифровать $data, выберите тип HttpOnly и поставил печенье.

когда пользователь вернется на ваш сайт, выполните следующие действия:

  1. получить данные cookie. Удалите опасные символы внутри куки. Взорвать его с : символ.
  2. проверка действительности. Если cookie старше X дней, то перенаправьте пользователя на страницу входа.
  3. если cookie не старый; получить последнее время смены пароля из базы данных. Если пароль изменен после последнего входа пользователя перенаправить пользователя на страницу входа.
  4. если пропуск не был недавно изменен, получите настоящее агента пользователя в браузере. Проверьте ли (currentUserAgentHash == cookieUserAgentHash). Если агенты одинаковы, перейдите к следующему шагу, иначе перенаправьте на страницу входа.
  5. если все прошел шагов успешной авторизации пользователя.

если пользователь выходит из системы, удалите этот файл cookie. Создайте новый файл cookie, если пользователь повторно входит в систему.

2

Я не понимаю концепцию хранения зашифрованных вещей в файле cookie, когда это зашифрованная версия, которую вам нужно сделать для взлома. Если я что-то упустил, пожалуйста, прокомментируйте.

Я думаю о том, чтобы использовать этот подход, чтобы "помнить меня". Если вы можете увидеть какие-либо вопросы, пожалуйста, прокомментируйте.

  1. создайте таблицу для хранения данных "Запомнить меня" - отдельно от пользовательской таблицы, чтобы я мог войти в систему из нескольких устройства.

  2. при успешном входе в систему (с запоминанием меня ставили):

    A) создайте уникальную случайную строку, которая будет использоваться в качестве идентификатора пользователя на этой машине: bigUserID

    b) сгенерируйте уникальную случайную строку: bigKey

    c) хранить cookie: bigUserID: bigKey

    d) в таблице" Запомнить меня " добавьте запись с: UserID, IP-адрес, bigUserID, bigKey

  3. Если вы пытаетесь получить доступ к чему-то, что требует логин:

    A) проверьте наличие файла cookie и найдите bigUserID & bigKey с соответствующим IP-адресом

    b) Если вы его найдете, войдите в систему, но установите флаг в пользовательской таблице "мягкий вход", чтобы для любых опасных операций вы могли запросить полный вход.

  4. при выходе из системы отметьте все записи" Запомнить меня " для этого пользователя как истекшие.

единственные уязвимости, которые я вижу, это;

  • вы может завладеть чьим-то ноутбуком и подделать их IP-адрес с помощью куки.
  • вы могли бы подделать другой IP-адрес каждый раз и угадать все это - но с двумя большими строками, чтобы соответствовать, что было бы...делаем аналогичный расчет выше...Я понятия не имею...огромные шансы?
2

Я прочитал все ответы и все еще было трудно извлечь то, что я должен был сделать. Если картинка стоит 1к слов, я надеюсь, что это помогает другим реализовать надежное постоянное хранение исходя из значения Улучшена Постоянная Практика Входа В Cookie

enter image description here

Если у вас есть вопросы, отзывы или предложения, я постараюсь обновить диаграмму, чтобы отразить для новичка, пытающегося реализовать безопасный постоянный авторизоваться.

2

реализация функции "Keep Me Logged In" означает, что вам нужно точно определить, что это будет означать для пользователя. В простейшем случае я бы использовал это, чтобы означать, что сеанс имеет гораздо более длительный тайм-аут: 2 дня (скажем) вместо 2 часов. Для этого вам понадобится собственное хранилище сеансов, возможно, в базе данных, поэтому вы можете установить пользовательское время истечения срока действия для данных сеанса. Затем вам нужно убедиться, что вы установили куки, которые будут держаться в течение нескольких дней( или дольше), а не истекают, когда они закрыть браузер.

Я слышу, как вы спрашиваете "почему 2 дня? почему не 2 недели?". Это связано с тем, что использование сеанса в PHP автоматически отодвинет истечение срока действия. Это связано с тем, что истечение срока действия сеанса в PHP на самом деле является таймаутом простоя.

теперь, сказав это, я бы, вероятно, реализовал более сложное значение тайм-аута, которое я храню в самом сеансе, и вышел на 2 недели или около того, и добавил код, чтобы увидеть это и принудительно аннулировать сеанс. Или, по крайней мере, чтобы войти их. Это будет означать что пользователю будет предложено периодически входить в систему. Yahoo! сделать это.

0