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

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

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

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

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

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

введение

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

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

печенье

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

bool cookie посредством setcookie ( строка $имя [, строка $значение [, инт $истекает = 0 [, строка $путь [, строка $домен [, bool и $secure = false [, bool $httponly = false ]]]]]] )

• secure (использование HTTPS связи)
• httponly (уменьшить кражу личных данных через XSS атаки)

определения

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

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

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

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

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

• нет никакого способа узнать, если печенье было украдено
• злоумышленник может получить доступ к конфиденциальной операции, такие как изменение пароля или данных, таких как личные и запекания информации и т. д.
• скомпрометированный cookie по-прежнему будет действителен для срока службы 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());
}

некоторые люди могут задаться вопросом, как вы можете использовать 2 разных куки ? Ну это возможно, представьте себе example.com = localhost и fakeaddsite.com = 192.168.1.120. Если вы проверите куки, это будет выглядеть так

С изображения выше

• текущий посещенный сайт является localhost
• он также содержит куки набор из 192.168.1.120

192.168.1.120

• только определенными HTTP_REFERER
• только принимает соединение от указанного REMOTE_ADDR
• нет JavaScript, нет контента, но ничего не состоят, а не подписывают информацию и добавить или получить его из cookie

преимущество

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

минус

• несколько запросов на сервер только для одного входа

улучшение

• готово использование iframe use ajax

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

• Постоянный Логин Cookie Лучшая Практика
• Улучшена Постоянная Логин Cookie Лучшая Практика

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

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

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

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

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

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

что все сказанное, есть два отличных способа иметь авто-вход в вашу систему.

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

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

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

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

несмотря ни на что, даже если злоумышленник использует 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

обратите внимание, что в этой таблице нет поля пользователя, потому что имя пользователя при входе в систему находится в данных сеанса, и программа не разрешает нулевые данные. 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-адреса по своей природе должны быть уникальными, поэтому имеет смысл, что каждая запись имеет уникальный значение. С другой стороны, имена хостов могут дублироваться в отдельных сетях на законных основаниях. Сколько людей используют "домашний компьютер" в качестве одного из своих компьютерных имен? Имя пользователя берется из данных сессии на сервере, так манипулировать невозможно. Что касается токена, тот же метод генерации токенов сеанса для страниц должен использоваться для генерации токенов в cookies для автоматической регистрации пользователя. Наконец, код datetime добавляется, когда пользователю необходимо будет повторно подтвердить свои учетные данные. Либо обновите это datetime при входе пользователя, сохраняя его в течение нескольких дней, либо заставьте его истекать независимо от последнего входа, сохраняя его только в течение месяца или около того, в зависимости от вашего дизайна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. при успешном входе в систему (с Запомнить меня галочкой):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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