Комментарии 25
Конечно, не точно. Насколько мне известно Telegram/Viber/WhatsApp не раскрывают особенностей серверной архитектуры в этой части. Если это не так — прошу меня поправить.
У статьи, грубо говоря, следующий посыл: если вы хотите организовать нечто похожее, но не знаете как — то вам сюда.
P.S. Немножко дополнил введение и в разделе про OTP добавил описание HOTP — это больше похоже на то, что используется в Telegram.
Это вроде как и есть brute force или вы что-то ещё имели ввиду?
Это хороший вопрос. Можно ограничить число СМС в час на определённый номер. Впрочем, ничто не мешает указать произвольное число номеров. Тогда можно банить IP, но ничто не мешает менять IP. В этом случае, можно блокировать регистрацию на время, но, судя по всему, если вас захотят задидосить таким образом — задидосят.
У вас есть соображения на тему?
Спасибо, что затронули эту тему. Обновил статью, и добавил раздел Безопасность, где дан ответ на тему противостояние прямому перебору. Перечислил два подхода, которые рекомендуются авторами стандарта.
1) на подтверждение кода дается 30 секунд. Дальше он истечет и нужно будет отправлять новый.
2) попытка подтвердить код в независимости от исхода этот код удалит отовсюду.
То есть подобрать можно только алгоритм.
Итого — берем пользовательские данные, время сервера и набор рандомных байт, делаем хеш, отображаем на числа 0..999999 (а можно и так — пусть пользователи помучаются) произвольным способом, и вуаля.
Алгоритм простой: человек ошибся с вводом кода, всё, надо ждать следующего. Натуральным образом (при ttl 30с) это даёт всего 2880 попыток в сутки. А дальше простой алгоритм, который увеличивает задержку после каждой следующей попытки. Очевидно, что человек не будет пробовать больше пары тысяч раз ни при каких обстоятельствах (тем паче, код надо не «вспоминать», а «набрать»), то есть увеличение задержки можно делать после пятой-шестой попытки.
Ну вот, я уже обрадовался было, что наконец-то Яндекс сделает двухфакторку по RFC, и я смогу его занести в свой MS Authenticator в тёплую компанию к
Гуглу,
Майкрософту,
Гитхабу,
Дропбоксу,
Фэйсбуку,
Вордпрессу,
Вконтакту,
и даже моему любимому Тайнипэссу, для которой я сам буквально пару месяцев назад её и реализовал (обкатывается на QA, скоро глобально включим).
Но нет. Оказывается, Яндекс изобрёл свой собственный нестандартный велосипед, для которого вдобавок нету приложения под WP.
Спасибо, Яндекс.
Да, вы правы насчёт ограничения или задержки. Просто важно об этом помнить. Я обновил статью и добавил раздел "Безопасность". Процитирую кусочек:
Посмотрим на примере. Пусть код TOTP состоит из 6 цифр — это 1000000 возможных вариантов. И пусть разрешено вводить 1 код в 1 секунду, а код живёт 30 секунд.
Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000 ~ 0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880 ~ 8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.
Вот тут и тут дискуссии на эту тему. Краткий вывод такой:
The only reason I could think of that would encourage the use of AccountManager would be if you want to share your account across a number of different apps, as the data is stored in the central Android datastore which can be accessed by all apps. However, if this isn't required, I think its probably easier and simpler to just use SharedPreferences
Т.е. если вам не нужно ваши данные аутентификации синхронизировать между многими приложениями, то да — Account Manager, если нет (что значительно чаще. если вы не Яндекс, Google и т.п.), то проще обойтись SharedPreferences.
По этой же логике двухфакторка тоже несекьюрна в принципе, т.к. любой, кто у установил слежение за вашим устройством (например, перехват ввода с клавиатуры) и к вашим СМС может с легкостью получить доступ к данным.
Тут корректнее говорить, о вероятности и сложности получения доступа. И тут вы, безусловно, правы. Двухфакторка значительно надёжднее. Но она — некоторый компромисс с удобством пользователя, и упомянутые Telegram/Viber/WhatsApp на него не идут, оставляя только СМС. За что, кстати, Телеграм уже платился.
Но, если у вас не такое критичное и важное приложение как мессенджер или инернет-банк, то, в целом, можно и пойти на этот риск. Конечно, если ценность ваших конкретных данных (к примеру, в приложениях такси) не сопоставима с затратами на перехват СМС.
Строго говоря, пока у вас нет 100% контроля на устройством (как его нет ни в случае iOS, ни в случае Android), говорить о том, что это чисто ваш промах не до конца корректно. Теоретически, кейлогер могут установить на заводе, в магазине или где-то в недрах Apple, или Google или Huawei и ему подобные. Кроме того существуют уязвимости нулевого дня, и опять же ваша вина будет только в том, что вы оказались в сети.
Превентивные меры в вышеописанных ситуациях тоже неясно, какие можно предпринять.
В целом, я комментировал фразу про то, чей промах, и помогут ли превентивные меры.
Кроме того, что касается Apple. Если им не западло удалять "пиратские" файлы с компьютеров пользователей, или Google не брезгует объявлять, что Android будет удалять пиратское ПО с телефонов пользователей, то я не вижу технических причин у этих компаний не перехватить ваши пароли. Только организационные.
У вас нет контроля над их ПО. Вы точно также доверяете свои данные их ПО, как вы доверяете свою переписку своему ОПСОСу.
Может показаться, что МТС себя скомпрометировало и попалось на этом, а Google и Apple — уважаемые западные компании и не позволяют себе такого. Так вот, согласно Guardian, это не так.
Ведущие американские ИТ-компании знали о том, что АНБ собирает данные их пользователей, и даже помогали агентству. Об этом сообщил главный юрист АНБ.
…
Он сообщил, что АНБ получала как содержимое сообщений пользователей, которые они пересылали друг-другу, так и сопутствующие метаданные.
Организация аутентификации по СМС по примеру Telegram/Viber/WhatsApp