Не совсем, там в RFC написано, что метод обновления токенов опционально может возвращать RefreshToken, это предполагает, что он может быть одноразовым. А конкретные рекомендации можно найти по ссылкам — раз, два
Да с чего вы взяли, что этим можно пренебречь? Вы же сами пишите
Нельзя заниматься одним и игнорировать второе.
И предлагаете пренебречь? Вы сами себе противоречите в рамках одного сообщения.
И никто не игнорировал фактор проверки сертификата, это обязательно делается, но скажу еще раз, статья не об этом.
Так у вас вообще расшифрованный токен по сети идет, бери и повторяй запрос.
Так не получится повторить, потому что токен уже не валиден. А в вашем варианте можно узнать пин по сети и вести его вручную.
А в моем варианте логин вводить не надо)
Это детали реализации, можно сделать сохранение логина и тоже не нужно будет вводить.
Нет таких векторов атаки, где ваш вариант устоит, а мой — нет.
Это не правда, если подумать шире. При передачи и хранении открывается большое количество векторов и возможностей где можно облажаться. Например, http клиент может закэшировать запрос в котором присутствует пин => при доступе к устройству будет и токен и пин. И таких возможностей открывается вагон. Главное понять, что в вашем варианте в бОльших системах фигуририует пин => его бОльших местах нужно защищать => больше вариантов налажать.
Конечно, не стоит это делать для каждого приложения. Сначала стоит определить уровень критичности приложения, например по MASVS, а потом уже заниматься такими вещами.
пин можно и в моем варианте изменить, причем локально на устройстве без отправки по сети.
разблокировку паролем от аккаунта
В моем варианте ничего не мешает ввести логопасс, тебе просто выдадут новые токены, а старые заинвалидируются.
И он безопаснее в некоторых сценариях. Например, Ева перехватила пакет
Да, интересный кейс, но он сработает только в случае владения 1 пакетом, а не каналом полностью. В целом, я все равно считаю, что вариант описанный в статье немного безопаснее.
Не отправлять токены гет, а отправлять пост. Не отправлять что-то там вместе с чем-то там. Автор ты серьезно? Если Ева слушает канал то не важно что и как отправляется. Если не слушает, то отправляй что как удобно.
Я не зря оставил ссылку в посте на CWE. С этой уязвимостью ты сколько угодно можешь проверять сертификаты, только это не поможет.
ПРОВЕРЯЙТЕ СЕРТИФИКАТ СЕРВЕРА. ХОРОШО ПРОВЕРЯЙТЕ
Основной посыл статьи не про сеть, а про хранение.
Итого статья безграмотна
Учитывая предложения выше, мне сложно сказать кто/что тут безграмотная.
Отвечаю сразу на оба пункта. Сам по себе утекший токен ничем не грозит, просто этот вариант реализации предполагает, что пин будет передаваться и храниться. Это открывает еще 1 поверхность для атаки, которая предполагает стилл пин-кода и ввод его на физическом устройстве(без доступа к данным). В описанном варианте невозможно извлечь ни токен ни пинкод. По-этому я и посчитал, что он немного лучше.
Никто не отменял, ровно так же как и уязвимости в этом шифровании. Как я писал выше, проблема в увеличении поверхности атаки и если мы передаем, храним пин-код, то его можно перехватить, угнать и воспользоваться им при физическом доступе к устройству.
1) Передача пина сама по себе увеличивает поверхность для атаки. Например, теперь его можно перехватить по сети(см пункт 2)
2) А смысл? Вариантов всего 10к. Это получается, что завладев базой, я могу составить радужную таблицу на 10к вариантов и найти по ней все пины? Даже если будет у каждого своя соль, то это только немного замедлит перебор, тк прийдется для каждого пин-кода строить радужную таблицу.
В целом я согласен, отключение буффера у пароля довольно спорная затея, не так давно OWASP выпилил эту рекомендацию в своих документах. Но риски определенно есть. И никто не заставляет вводить пароль руками. В новом андройде, например, появилось API для автозаполнения кредов.
И никто не игнорировал фактор проверки сертификата, это обязательно делается, но скажу еще раз, статья не об этом.
Это детали реализации, можно сделать сохранение логина и тоже не нужно будет вводить.
Это не правда, если подумать шире. При передачи и хранении открывается большое количество векторов и возможностей где можно облажаться. Например, http клиент может закэшировать запрос в котором присутствует пин => при доступе к устройству будет и токен и пин. И таких возможностей открывается вагон. Главное понять, что в вашем варианте в бОльших системах фигуририует пин => его бОльших местах нужно защищать => больше вариантов налажать.
Спасибо за комментарий.
пин можно и в моем варианте изменить, причем локально на устройстве без отправки по сети.
В моем варианте ничего не мешает ввести логопасс, тебе просто выдадут новые токены, а старые заинвалидируются.
Да, интересный кейс, но он сработает только в случае владения 1 пакетом, а не каналом полностью. В целом, я все равно считаю, что вариант описанный в статье немного безопаснее.
Я не зря оставил ссылку в посте на CWE. С этой уязвимостью ты сколько угодно можешь проверять сертификаты, только это не поможет.
Основной посыл статьи не про сеть, а про хранение.
Учитывая предложения выше, мне сложно сказать кто/что тут безграмотная.
если ты воспользуешься перехваченным RefreshToken, то пользователь сразу об этом узнает, тк его разлогинит.
Если ты можешь перехватывать, то перехватишь и DeviceId и представишься все тем же девайсом.
2) А смысл? Вариантов всего 10к. Это получается, что завладев базой, я могу составить радужную таблицу на 10к вариантов и найти по ней все пины? Даже если будет у каждого своя соль, то это только немного замедлит перебор, тк прийдется для каждого пин-кода строить радужную таблицу.