РНР-безопасность: где и как хранить пароли. Часть 2

[Mylistryx]

Какой то кусок текста из официальной документации, если честно.
Как насчет password_needs_rehash?
В первый раз слышу про настройку cost. Судя по статье — поставлю я cost=1, менее 100мс? Менее! Зачем её вообще трогать то?
IMHO, статья ради статьи.

[php7]

Напишите, пожалуйста, о том, как работать с авторизационной кукой, что туда писать.

[dady_KK]

Не ради холивара, а что именно Вы хотите туда писать, например: есть сессионная кука с идентификатором сессии, по которому сервер сверяется с самими сессиями и уже на основании того, что есть в сессии делает выводы. Зачем ещё авторизационная кука, чтобы использовать вместо сессий? Так и сессионная кука насколько я понимаю для этого подойдёт, единственный выигрыш — устанавливать различное время жизни для разных печенек, или есть какие-то ещё плюшки?

[VolCh]

Отказаться от сессий в принципе можно, следуя REST архитектуре. Особенно полезно в случае если несколько реплик запущено и лоад балансер перед ними.

[php7]

Допустим есть галочка при авторизации «Запомнить меня».
Это что, сессии должны жить год?

[Mylistryx]

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

[php7]

А чтобы не хранить на сервере?

[Mylistryx]

С трудом себе это представляю. Пользователь может менять на своей стороне COOKIE как угодно, значит хранить данные там не безопасно. Т.е. записать в куку ID пользователя или что-то подобное — так себе идея. При очень большом желании можно зашифровать всё это ключем хранимым на сервере и расшифровывать им же, но мне кажется проще вариант с token.
Есть еще вариант с Fingerprint, но я никогда его не использовал, только читал про это, помоему даже здесь, на хабре.

[Mylistryx]

От чего это защитит? От правки пользователем? Это защита от XSS, не более.

[BoShurik]

Например, в Symfony данные в куке подписываются с помощью секретного ключа, чтоб их нельзя было подделать

[Mylistryx]

Посмотрел, да, интересная реализация. Позволяет обойтись без токенов и если пользователь сменит пароль, то по куке уже не войдет. От подделки кук защищает хэш.
php7 — вот то, что вам надо!

[iig]

Можно в cookie сохранить сертификат SSL со сроком действия в 1 год, и проверять его валидность. А что не так с хранением токена на сервере? + 2 поля (токен и срок действия) в таблице, которая и так есть.

[Mylistryx]

В Yii2 даже проще, $token = TOKEN_STRING_TIME
Проверяется через explode('_', $token), сначала TIME, что не протух, потом уже сам токен.
Но я обычно переделываю и храню токены в отдельной таблице с внешним ключем и указанием типа токена. Дает возможность хранить все связанные токены в одной таблице, подчищать протухшие, ограничивать кол-во в целом и по времени.
Но что то мы из комментариев тостер тут устраиваем.

[dso]

Тогда токен jwt, который подписывается своим приватным ключом. Токен в бд можно не хранить.

[Mylistryx]

Смысл от этого действия? Просто пустить в систему? Если мы не храним этот токен в БД, то к какому пользователю он относится? Выше ссылка на шикарный пример из Symfony!

[dso]

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

[0x131315]

Вообще хранить токены в БД полезно еще для одной фишки: отображение, верификация и управление множественными авторизациями.

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

[Mylistryx]

user
---
id
*

user_token
---
id = > uuid
user_id = ralation uuid
token => random string (unique)
type => in UserToken::range()
data => json

Как по мне — идеальная схема.
Можно еще created_at и прочее, но у нас есть json!