Небезопасный сервис про безопасность

[SanSYS]

Без тестирования такого сценария в стейджинге сразу действовать в проде — это очень смело, конечно )

[Stravnik]

Это не смело, а очень глупо.

[xxxphilinxxx]

В дополнение к комменту от mals: мне кажется, вы даже сейчас в статье не то называете главной проблемой. Опасно то, что токен генерируется повторяемо (!) из логина. У вас есть для этого особое требование?
Вечный токен — конечно, риск, но на описанную ситуацию вы бы нарвались даже с короткоживущим токеном, достаточно уложиться в срок его жизни.
UUID вместо порядковых ID помог бы с конкретным случаем, но что, если токен пользователя скомпрометирован? Как его заменить? Или, что еще хуже, скомпрометирован алгоритм получения токена из логина?
ИМХО более безопасным подходом будет создание случайного токена, а затем связывание его с пользователем. Получаем возможность создавать множество токенов для пользователя и легко их отзывать, не вкладываем никакой информации о логине в токен, можем даже спокойно оставить инкрементный ID.

[Cuckooshka]

и вечный токен, который генерировался однозначно из этого id.

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

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

Здесь не согласна. Короткоживущий токен содержит информацию о времени жизни, а это уже даст разные токены для одинаковых id, тк добавляет еще одну зависимость в генерацию.

[xxxphilinxxx]

А, хорошо, значит, мне показалось :)
Но с короткоживущим токеном я все равно вижу потенциальный риск в реализации: сам токен может быть шифрованным контейнером, содержащим, например, ID пользователя и дату создания. Тогда можем получить старый токен, расшифровать, проверить ID и дату, но тоже ошибочно аутентифицировать пользователя. Поэтому как раз хотел подчеркнуть, что стоит избавиться от информации о логине в самом токене.

[Cuckooshka]

Согласна, сам подход для генерации токена лучше использовать другой. История со сроком жизни токена — из серии «вот если бы хотя бы не… то ничего бы не произошло». Если бы мы по-тупому не генерировали токены или хотя бы uuid при генерации использовали или срок жизни, если бы мы не удалили пользователей из базы, если бы мы прогнали сценарий на тестовой площадке и т.д и т.п.
Но факапы рождаются, только если они продрались через этот лес условностей)

[xxxphilinxxx]

О да, самые интересные истории получаются, когда такиие звезды сходятся… из забавных мелочей вспомнилось: у меня когда-то в древности был проект на поддержке с рассылкой ежемесячных отчетов. В один Новый Год между отчетами пропала целая неделя. Расследование показало, что изначально в проект вкралась ошибка с определением принадлежности рубежной недели к уходящему или к грядущему году. Несколько лет эта бомбочка мирно тикала и накапливала сдвиг, после чего снесла неделю из отчетов.

[Cuckooshka]

Не горжусь этой историей, но и не считаю, что ее стоит замалчивать. Да, мы накосячили. В команде не было многоопытного товарища, который сказал бы — ребята, так не делается. Сами же мы тогда посчитали, что быстрое и работающее решение — достаточные критерии качества. Опытным путем выяснилось, что это не так

[Tamahome]

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