SymphoGraph, ну у нас в шкиле был прикол такой, я заметил что в электронном дневнике если 3 раза неправильно ввести пароль к учетке, а логины были циферные idшники, но не так что 1, 2, 3, 4, 5 и т.д., а просто 12 значные вроде или 10 значные циферные логины, они не были рандомными, а выделялись пулами на школы или еще как. Так вот, зная логин учетки можно было простым скриптом забанить вход учителя/завуча/директора или ученика в электронный дневник. Можно было это делать по кд (не давая вообще войти) или только когда учитель захочет зайти поставить оценки. Так вот, мне приснилось (мы так не делали), что один наш одноклассник написал тг бота в которого можно было добавлять логины учеток и выбирать как их банить (единоразово или на постоянке).
Тут тоже самое, если будет слита база номеров клиентов или она будет предсказуема (например, мы заранее знаем номера людей которые зареганы в сервисе) то мы сможем парализовать работу системы аутентификации для конкретного человека или веерно (просто тупо спамить запросы на все известные нам номера)). Если же разрабы поймут что никто не может зайти в свой кабинет то они начнут в панике либо снимать ограничения попыток входа, либо еще что делать, что позволит абузить уже бесконечные попытки входа/ввода кода из смс, что делает уязвимыми аккаунты пользователей.
В описанном выше случае уже применяют другие способы защиты, в том числе анализ данных с помощью машинного обучения. Если коротко и быстро то тупо ставят защиту от дудоса с блэкджеком и ... кхм кхм, защитой от ботов.
SymphoGraph, с чего бы это? В контексте вопроса автора токен это секретная строка, которую генерирует сервер и отдает клиенту при отправке кода смс. Этот токен используется чисто для того чтобы обезопасить процесс аутентификации пользователя.
ITDown, принято сейчас использовать https соединение, где перехват токена затруднителен. Почти единственный путь - это вирус на устройстве пользователя, который вытащит токен откуда угодно, поэтому защищать токен особо смысла нет, тем более в промежутке 5 минут (время действия кода из смс и токена). Если кому то надо будет перехватить токен то он это сделает в любом случае как бы ты не защищался. Единственный плюс в таком случае httponly cookie это защита от зараженных библиотек фронтэнда которые могут сливать данные куда-то на сторону.
ITDown, перехватить можно че угодно, поэтому разницы нет особой, делай как удобно. Я лично не пишу никогда токены в куки, передаю на клиент в теле ответа jsonом. На клиенте также никуда не сохраняю кроме переменной. То есть не пишу токен в куки/локалсторож или еще куда. Тупо const token = response.token
WSGlebKavash, я хз что это бро, какой-то софт взломали или специально в него внедрили закладку которая тырит с компов разрабов tdata - мое мнение. Если ты не дурачок который вводит на фишинге доступ к своей тг и сидишь на линуксе то больше то и вариантов особо нет.
WSGlebKavash, сделай ревизию всех софтов что ты юзаешь и мониторь уязвимости пофикшенные там. Периодически выходят патчи и там пишут что пофиксили. Вообще стиллеры тихо отрабатывают обычно и выбрасываются за борт. Если это ботнет то может быть и засел. В 99% случаев лучше переустановить систему и не допускать ошибок снова) Вообще это стандартная тема, когда хотят прогреть разрабов такими вирусниками - народ в большинстве своем богатый, с криптой))), да еще и доступ к какой-нибудь рабочей системе можно получить, зашифровать и шантажировать потом. Это дефолт.