Как выглядит логика простой системы авторизации с «выходом на всех устройствах»?

Question

[Barrakuda74]

При этом используя только PHP, MySQL, сессии и куки (без redis'ов, мемкешов и т.д.).
Просто когда начал писать восстановление пароля (по сути сброс, новый приходит на почту юзеру), понял что по логике здесь должен быть "выход на всех устройствах", а как организовать, не пойму.

Админки до этого как-то особо не нужны были, поэтому использовал их только для своих самых маленьких нужд с простой записью auth=true в сессии. По выключении браузера сессия терялась. Знаю что можно увеличить жизнь сессии, но вроде как не рекомендуют, пишут лучше потом восстанавливать их по кукам(дополнительные видимо ещё ставить, не сессионные) или токенам в БД (не сталкивался). Вот хотел спросить чего куда записывать-то в итоге, чтобы можно было потом различать авторизации пользователя с разных устройств, и чтобы разом их можно было снести при сбросе пароля?

Пока образно могу себе как-то так представить:

1. Авторизуемся -> заполняем сессию, записываем дополнительную (долгосрочную, напр 3 дня) куку с рандом-строкой (mycoockie = "dsf34Nrty4d4dftlk5r4g5") для восстановления сессии, записываем в БД в таблице sessions эту же самую строку ("dsf34Nrty4d4dftlk5r4g5") и ID пользователя, кому принадлежит сессия.

открываем след. страницу:

2. Если есть сессия -> работаем (или тоже постоянно сверять чтобы были какие-то актуальные данные в БД, ведь возможно я злоумышленник, а реальный пользователь воспользовался сбросом пароля, т.е. меня должно сразу выкинуть).

3. Если пропала (закрывали браузер или 24 минуты неактивности что вроде по умолчанию для сессий), проверяем куку (mycoockie), и если в ней какая-нибудь рандом-строка. -> проверяем наличие этой рандомной строки в БД, если найдена, то восстанавливаем по ID напротив этой строки данные юзера.

Answer 1

[AHTUxPK]

У меня реализовано следующим образом:

Есть в БД таблица sessions с полями current_session, long_session, user_id и login_time.
При успешном логине генерируются две случайные строки. Первая записывается в стандартную PHP сессию и будет current_session. Вторая записывается пользователю в куку session, а хеш этой строки будет long_session. user_id - идентификатор пользователя, login_time - время логина.

Проверка, залогинен ли пользователь, выполняется следующим образом:
1. Если у пользователя есть активная PHP сессия, проверяем, активна ли его current_session, если да, то пользователь авторизован.
2. Если у пользователя нет текущей сессии, но установлена кука session, то ищем хеш от неё в базе. Если запись есть и с момента последнего логина прошло меньше указанного количество времени (я использую меньше трёх месяцев), то по user_id берём остальные данные пользователя и создаём текущую сессию, пользователь авторизован.

При logout просто очищаем текущие current_session и long_session. Если нужно разлогинить везде, то очищаем все эти значение по user_id.

Такой подход позволяет строго управлять сессиями с помощью БД, но при этом стандартный механизм PHP сессий позволяет хранить разнообразную информацию, типо csrf токенов, не захламляя базу.

Comments

[Barrakuda74]

Вот вроде как раз что-то очень такое близкое и понятное мне.
Хотелось бы ещё уточнить некоторые нюансы в данной реализации.
1. Если пользователь авторизуется ещё раз где-то с другого устройства, вы не перезаписываете current_session с тем же user_id, а создаёте новую запись в БД? (т.е. таким образом реализуется сохранение всех сессий одного и того же пользователя). В итоге я так понимаю в БД хранятся все сессии в течение 3х месяцев (или меньше, сколько указано) от посл. login_time.
2. Login_time если я правильно понял, он каждый раз при восстановлении авторизации обновляется (если да, то каждый раз при очередном любом запросе авторизованного пользователя, или только по восстановлении авторизации по кукам)? Ну и CRON'ом я так понимаю мы каждый день потом просто очищаем таблицу sessions от сессий где login_time больше 3х месяцев.
3.

При успешном логине генерируются две случайные строки. Первая записывается в стандартную PHP сессию и будет current_session. Вторая записывается пользователю в куку session, а хеш этой строки будет long_session.

Можно ли здесь поподробнее. Так, одну строку записываем напр в сессию как x="qw34tben...", и сверяем полю current_session в БД, другую строку записываем в куку как y="m4jhseweg2", т.к. она у нас будет долгоживучей (сколько кстати у неё срок действия ставите, и обновляете ли вручную её срок действия при восстановлении авторизации?), и сверяем её с хэшем в БД (long_session) от этой же строки. А почему первую строку храним в открытом виде, а long_session храним только хэш от случайной строки и сверка по хэшу? На ум вроде приходит что злоумышленнику недостаточно будет узнать current_session для получения доступа, т.к. нужно ещё знать сессионный идентификатор (PHPSESSID), чтобы зайти на сайт и пользователь его вспомнил, а во втором случае злоумышленнику достаточно узнать исходник строки long_session для входа, поэтому его кодируем, верно?

В целом реализация выглядит очень простой и крутой, то что надо, и вроде как без изъянов, ещё вот нюансы разобрать, и практически пошаговое руководство :)

[AHTUxPK]

1. Да, успешная аутентификация - новая сессия и соответственно запись в БД. Хранить можно сколько угодно, ещё и пользователю полезно показывать историю входов в аккаунт.

2. Я не обновляю время логина, чтобы хотя бы иногда приходилось снова логиниться, но вполне можно это делать.

3.

Можно ли здесь поподробнее. Так, одну строку записываем напр в сессию как x="qw34tben...", и сверяем полю current_session в БД, другую строку записываем в куку как y="m4jhseweg2", т.к. она у нас будет долгоживучей

Да, всё так

сколько кстати у неё срок действия ставите, и обновляете ли вручную её срок действия при восстановлении авторизации?

Столько же, сколько у сессии - 3 месяца, но, как и во втором пункте, вполне можно обновлять

сверяем её с хэшем в БД (long_session) от этой же строки. А почему первую строку храним в открытом виде, а long_session храним только хэш от случайной строки и сверка по хэшу?

Первая используется только для связывания БД и стандартного механизма сессий, пользователь её не видит. А вот с long_session немного другая история. Так как её знание позволяет получить полный доступ к аккаунту, то и защищать её нужно как пароль, то есть хешировать (пароли ведь мы не храним в открытом виде), чтобы при возможном взломе базы не было доступа к аккаунтам. Также и про длину этой строки нужно не забывать, чтобы её было бесполезно подбирать.

[Barrakuda74]

Всё понятно, благодарствую :)
Пойду таким же путём.

Answer 2

[xmoonlight]

Смена токена учётки на сервере и привед при следующем запросе.

Comments

[Barrakuda74]

Смена это т.е. если авторизоваться с другого устройства? как тогда делают? наверное в этом случае можно ещё какие-то данные сохранить в БД для отличия авторизаций одного юзера (эмм, юзерагент?)

[xmoonlight]

Barrakuda74, нет. смена - это действие logout.
Или логин со сбросом сессии на других устройствах.

По списку - я уже отвечал тут (на тостере):
Связка такая: UserID (логин+пасс) -> клиент(устройство) -> token

token=token (сессионный)

Все токены - сессионные (разные) и для конкретного устройства юзера.
Можно сделать сессионный токен - составным: добавив ЕДИНЫЙ ДОПОЛНИТЕЛЬНЫЙ ЦЕНТРАЛЬНЫЙ токен для учётки (уже без зависимости устройств!).

token=token (сессионный) + token (account)

Соответственно, формирование/проверку сессионного токена - делаем тоже составной.

При смене этого центрального токена учётки, все токены сессии становятся СРАЗУ невалидными и происходит блокировка действий и logout для абсолютно ВСЕХ сессий этого юзера (кроме текущей, новой).

[xmoonlight]

Barrakuda74,

т.е. меня должно сразу выкинуть

при очередном ЛЮБОМ запросе к серверу - да.
Можно сделать по аяксу раз в 10 секунд проверку сессии... чтобы выкидывало автоматом.

[Barrakuda74]

UserID (логин+пасс) -> клиент(устройство) -> token

Если я правильно понимаю, это то, как формируется токен. Не совсем понимаю что в данном случае является "клиентом(устройством)", чему равен этот параметр. И userid равный логин+пароль, безопасно ли это, или имеете в виду хэш от всего этого? А с чем потом сверять этот токен? Ведь пользователь не отправляет нам каждый раз логин+пасс. Запутался короче(( Мне бы увидеть блин как это на деле организовано чуть подробнее, чего в какое поле записывать при авторизации/прогулке/logout/сбросу и с чем что сверять при идентификации.

при очередном ЛЮБОМ запросе к серверу - да.
Можно сделать по аяксу раз в 10 секунд проверку сессии... чтобы выкидывало автоматом.

xmoonlight, нет-нет, имел в виду при очередном запросе, конечно же.

[xmoonlight]

Barrakuda74, клиент - идентификатор устройства, обычно ID, формируемый по какому-то единому алгоритму.
userID - идентификатор аккаунта, разумеется хэш.

Пользователь при авторизации меняет логин+пасс на токен сессии. Затем, с помощью токена сессии и подписи запросов он общается с серверным API.

токен - хранится на сервере и на клиенте. Клиентский сверяется с серверным.
Почитайте здесь про API и авторизацию

[Barrakuda74]

xmoonlight, Прочитал, спасибо. Тоже интересно. Немного другой я так понял там подход. В основном всё на клиенте генерится, что больше для клиентский приложений годится. В моём случае у меня обычный сайтец в основном где кликать надо по страницам, выберу всё таки тот вариант (в выбранном ответе), он мне как-то более лёгким показался.

[xmoonlight]

Barrakuda74, ну там принцип - тот же.
ЕДИНЫЙ ДОПОЛНИТЕЛЬНЫЙ ЦЕНТРАЛЬНЫЙ токен для учётки = token (account) = long_session (в выбранном решением ответе...)
А разница лишь в том, что я формирую токен сессии вместе с long_session, а AHTUxPK - раздельно это делает. Ну я думаю, что вместе (связкой) - надёжнее. Менять нужно - только в одном месте и всё. А у него - нужно очищать все поля.
Вот и вся разница)

[Barrakuda74]

xmoonlight, до меня дошло наконец-то:)))) У вас просто так много переменных, они сбили меня с толку) Там видите у нас просто две рандомные строки (у AHTUxPK). Плюс user_id у него скорее всего то же имеется в виду, что и у меня (а у меня это обычно простые числа по порядку 1,2,3,4 и т.д. [которые в таблице "users" идут первой автоинкрементной колонкой с названием ID]), т.е. номер, по которому мы потом получаем данные юзера из другой таблицы ("users"). А у вас userID это сложный алгоритм из хэша(логин+пасс), я если честно не вижу просто дальнейшего применения получившейся строке, вроде как обычная рандомная строку получается. Что касается идентификатора устройства, то тоже почему-то не вижу применения. Подскажите если что почему лучше их использовать чем просто рандомные строки.
Итак. Извиняюсь что немного упросил вашу схему, хочу просто понять как работает. В БД у нас что-то вроде такого:
users, напр столбики.:

id   email       login       hash_pass(bcrypt от пароля)
1    [e-mail]     vasya       s2rg22eg
2    [e-mail]     petya       de45uymn

---
sessions, напр столбики.:

id  userid(=id из табл users)       type(0-session,1-account)           token                                            timestamp
1   1                               0                                   sessionToken	
2   1                               1                                   password_hash(accountToken)

---
Пояснение к формированию token для БД:

function randomStr(length) {...}; // форм. случ. строки
$sessionToken = random(30); // В БД попадает в чистом виде
$accountToken = random(30); // В БД попадает password_hash($accountToken)

При первой авторизации в БД пишем то что выше только что написал, а в куку пишем:

setcookie('token', $userID . ":" . $accountToken) // $userID здесь и далее просто порядковый номер из таблицы users (колонка ID)

В сессию пишем 3 переменные:

$_SESSION['userID'] = $userID;
$_SESSION['session_token'] = $userID . ":" . $sessionToken . ":" . $accountToken;
$_SESSION['ip'] = $userIP; // текущий IP
$_SESSION['UA'] = $userUA; // текущий UserAgent

При след. запросе проверяем:

if (isset($_SESSION['session_token'])) {
    // делим составной токен на 3 части (через двоеточие) и раскидываем по переменным
    // $userIDfromSession, $sessionTokenFromSession, $accountTokenFromSession;
    if ($_SESSION['ip'] != $userIP && $_SESSION['UA'] != $userUA) {
        // заставляем авторизоваться (т.е. если сменился одновременно IP и UserAgent)
    }
    // достаём токены из БД через $userIDfromSession, получаем переменные: $sessionTokenFromBD, $accountTokenHashFromBD
    if ($sessionTokenFromSession == sessionTokenFromBD) { // проверка сессионного токена
        if (password_verify($accountTokenFromSession, $accountTokenHashFromBD)) { // проверка аккаунтского токена
            // успешно авторизован (тут правда ещё проверка на срок login_time)
        } else {
            // заставляем авторизоваться (если сменился аккаунтский токен: logout, сброс пароля и т.д.)
        }
    } else { // если сессионный не подходит
        // вот здесь я не знаю нужно ли пытаться восстановить авторизацию по аккаунтскому токену из той же сессии или
        // из куки, если он не подходит или просрочен, или вообще сразу заставить авторизоваться...
    }
} elseif(isset($_COOKIE['token'])) {
   if (password_verify($_COOKIE['token'], $accountTokenHashFromBD)) {
       // успешно авторизован (тут правда ещё проверка на срок login_time)
       // и заполняем сессионные данные
   }
} else {
    // заставлям авторизоваться
}

При logout, сбросе пароля, блоке пользователя и т.д. генерируем новый accountToken, получаем его хэш через password_hash и получившийся результат засовываем в БД (таблицу sessions) через:

UPDATE `sessions` SET token=$NewHashaccountToken WHERE userid=$userID and type=1;

Сильно ли промахнулся?)

[xmoonlight]

Barrakuda74, В "молоко" даже не попали)
Про UserID:
1. По-скольку, он хранится на клиенте, то там должна храниться HASH-строка, однозначно идентифицирующая юзера на сервере при передаче пакета.
2. Юзер на сервере - это ID, логин и т.д., и ОТДЕЛЬНАЯ ЗАПИСЬ: UserID - это как раз и есть клиентский хеш.
3. Хеш пришёл - мы по нему восстановили логин(alice,bob,eva) и ID (1,2,3,,,,N).

Такой подход позволяет полностью обезличить пользователя ВЕЗДЕ (клиент и/или сервер) или задавать любое произвольное имя пользователя через его ЛК по его выбору (включая дубляж по всему сервису, если админы пожелают).
Т.е. мы UserName приравниваем к DisplayName, тем самым повышая безопасность.

Безопасность (например, украли телефон): Не зная логина и пароля - подбирать доступ непонятно к чему - немыслимая затея)

PS: кстати, если хотите (а я вижу, что хотите :) ) проработать свою идею до блеска - можете написать мне в почту и там - дошлифуем!

[Barrakuda74]

xmoonlight, отправил свой емейл через форму заказа рекламы на googledocs, а на сайте что-то лазил-лазил, но емейл так нигде и не нашёл))

[xmoonlight]

Barrakuda74, в профиле. (я - ответил.)