Двухфакторка, какой она должна быть

Posted: 2019-08-18 in IT, Security
Метки:, , ,

Всем привет. Сегодня мы поговорим про двухфакторную аутентификацию, или если более широко — о дополнительных способах усиления / защиты аккаунта через дополнительные факторы аутентификации.
Если вам интересна эта тема, и вам таки есть что скрывать, например данные вашей банковской карточки, приглашаю вас в избу-читальню.

Изначально идея 2FA возникла в тот момент, когда внезапно выяснилось, что во многих утёкших базах данных у огромного числа пользователей стоят слабые, легко взламываемые пароли, давно входящие в распространённые словари. Убедить бесчисленные орды пользователей поменять пароли на более стойкие оказалось невозможно, да и слишком для них болезненно, ограничения на число попыток с последующим локом учётки, как в банкомате, применить оказалось тоже затруднительно, так ещё и оказалось, что действительно стойкий пароль не так и просто придумать. Например, пароли типа m4n4sx3v3r, 50nl4512 или 3lla70ia — весьма слабые против оффлайн-атаки на утёкшую базу.

Конечно, были ещё попытки применять соление/перчение и всякие извратные хэш-функции. Но тяжелые хэши типа scrypt больше зашли для криптовалют (и то с рядом оговорок), тогда как крупные сервисы по понятным причинам послали это на хер — никакой крупный и нагруженный сервис не будет выделять по 100 Мб оперативки и 5 секунд расчётов на одну проверку пароля. Много где пароли до сих пор лежат открытым текстом. Да и переписывать крупный масштабный софт — зело недёшево. Соление — дело несомненно благое, и если есть возможность — делать его надо, но защищает только от массового вскрытия по радужным таблицам «одним запросом». Пароль типа 1234 что с солью, что без, сопротивляться современным техникам брутфорса абсолютно не способен. Есть и ещё один момент — у пользователей со слабым паролем другие пароли тоже часто оказывались не сильно крепче.

И тут кто-то вспомнил, что у пользователей есть такая штука, как сотовый телефон. На котором правда доступом в сеть рулит не сам пользователь, а оператор мобильной сети, полностью контролирующий как работу своих биллингов / базовых станций, так и внутренний микрокод на сим-карте, в том числе внутренние ключи симки ! На момент зарождения этой идеи большинство телефонов ещё были дубовыми кнопочными звонилками, которые были практически не подвержены вирусным заражениям.
На первый взгляд всё было хорошо — пользователь логинится, и сервис с разной степенью настойчивости просит (или требует) привязать номер телефона. Запуганный «злыми хакерами» клиент с радостью и восторженными визгами привязывает телефон к аккаунту, и затем процедура логина удлиняется на один шаг — сперва логин/пароль, потом код из СМС.
Теперь для логина нужно _ЗНАТЬ_ пару логин/пароль и _ОБЛАДАТЬ_ доступом к телефону в заданным номером.
Казалось бы, всё надёжно.

У некоторых иллюзия этой мнимой «псевдо-надёжности» была столь сильна, что звучали даже идеи вообще упразднить пароли, оставив только СМС-ки. Проблема в том, что в революционном порыве собрать побольше личных данных и поспамить назойливыми звонками произошла подмена понятий. Дело в том, что клиент _ОБЛАДАЕТ_ лишь физическим устройством — телефоном. А вот _НОМЕР_ ему как раз таки не принадлежит, никогда не принадлежал и _принадлежать_ скорее всего никогда не будет, во всяком случае в классической телефонии 100%. Номер телефона — это сущность, всеми свойствами и доступами к которой целиком и полностью рулит оператор связи.

Некоторые наиболее дальновидные люди уже тогда предупреждали, что эта идея довольно порочна, даёт возможности шпионить за пользователем, связывать его аккаунты вместе, спамить, а также создаёт много рисков со стороны нечистых на руку сотрудников ОПСОСов.
Как обычно, нашлись тупые наивные идиоты, которым как обычно было «нечего скрывать», ибо они «законопослушные и ни разу не террористы», и вообще «спецслужбы давно всё про всех знают». Возражения по этому пункту у меня принимаются только от тех, кто либо не пользуется банковскими картами принципиально, либо готов оставить в публичном месте их номер, дату действия и коды CVV/CVC, ведь вам «скрывать нечего, епт».

Но самый звиздец начался, когда всякие сервисы и системы начали использовать СМС-ки не только для кодов двухфакторки, но и для восстановления основного пароля, и даже для первичной аутентификации. Как только это случилось — всё, никакой двухфакторки у вас нет.

Есть только авторизация по номеру сотового телефона. Некоторые специалисты резонно заметили, что в таком случае аккаунт без такой херовой 2FA, но со стойким паролем, защищён в итоге куда лучше, чем аккаунт, где одним и тем же способом можно сделать и сброс первого пароля, и получение второго.

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

— выяснилось, что против некоторых пользователей онлайн-банкинга мошеннический перевыпуск сим-карт применялся многократно

Проблема в том, что из-за обилия собираемых данных и совершенно распиздяйского отношения к их обработке эти самые данные, несмотря на все принятые законы, относительно легко доступны для пробива самым разным прохиндеям.

Причём бизнес-аккаунты особенно вкусны для такой атаки.

А когда речь заходит о действительно крупных деньгах, то даже крупнейший оператор связи в США сделать уже ничего не может, так что проблема отнюдь не ограничивается коррупцией — тут идея дефективна изначально.

Это заметили в NIST, но кто ж его читает-то. И обосрались тут абсолютно все — от крупных банков до криптовалютных бирж.
Особо доставляет тот факт, что за косячный перевыпуск сим-карт наказывают … примерно никак. Ну, может на планёрке поругают.

Так что если вы пишите какой-то сервис, где вам нужна надёжная двухфакторка (а не просто чтобы РКН от вайфая отъебался), то никаких смс там быть не должно. И уж упаси вас макаронный монстр использовать смс-канал для сброса доступов при включенных смс-2фа !

У меня есть ряд идей на эту тему.

— 2ФА опциональна. Требовать привязывать второй фактор недопустимо. Предложить — да, предупредить о рисках — да. Требовать — нет. Исключения допустимы разве что для сайтов типа госуслуг или банков, и то, если будут исправлены текущие косяки. Остальных с их требованиями стоило бы послать подальше.
Пример мудаков тут — трупо-аська и вконтакт. Хотя один банк тоже заставил меня понервничать.

— Навязчивость и уровни 2ФА должны зависеть от баланса / ценности аккаунта. Очень глупо требовать сильной защиты для пустого аккаунта. Она там просто не нужна. А вот если там что-то ценное появилось — разумно со стороны сервиса предложить усиление защиты.

— методы должны быть разные, на выбор. Кому-то удобнее карточки одноразовых кодов, кому-то — TOTP, кто-то готов получать коды хоть в почту, хоть в смс, хоть голубями, кто-то желает аппаратный крипто-токен. 2ФА — неприятная вещь для пользователя, и наличие выбора методов — один из путей эту боль облегчить.

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

Методы разной степени доброты.

Я заинтересовался темой 2ФА и её проблемами примерно пару лет назад, и для себя отсортировал их примерно так:

— не использовать 2ФА вообще. Для кучи сервисов есть идея получше — на стороне сервиса при логине проверять, не входит ли пароль в словарь слабых и не пуст ли аккаунт. Если оба условия верны — настоятельно предложить усилить пароль. Лимитировать число попыток логина с одного IP-адреса в заданный интервал времени.

— СМС-ки. Для затыкания темы с публичным вайфаем, чтобы ркн отвял — кое-как и жопой об косяк — сойдёт.
Проблема в том, что этот фактор крайне трудно сменить пользователю и относительно легко — мошеннику, а должно быть наоборот.
Что-то особо ценное доверять смс-кам нельзя. Совсем. Да и отправка смс стоит денег, и деньги на балансе для рассылки смс часто кончаются в самый неподходящий момент.

— EMail. Как ни странно, лучше СМС-ок. Провайдеров почты много, и можно поднять свой сервер. В отличие от SS7 и телефонных протоколов, там местами есть TLS, да и на каждый сервис можно завести свою, чисто для 2ФА. В этом случае хак почты не станет вселенской катастрофой, как в случае с смс. Но надо понимать, что почта ходит местами открытой, каждый промежуточный сервер можёт её перехватить. Мода на TLS неслабо снизила этот риск, но не устранила его полностью.
Так делает одна криптовалютная биржа. Это легко закодить, и вполне надёжно и удобно.

— OTP / TOTP / Google Authenticator.
Весьма неплохи на первый взгляд. Но их слабое место — общий секрет. Для синхронной генерации правильных кодов нужно обоим сторонам знать этот чертов секрет как он есть, в открытом виде. Один утёкший бэкап или невнимательный сотрудник — и у мошенников появляется возможность генерить такие же коды, как и у вас.

— смарткарты и аппаратные токены.
Очень классная идея. На первый взгляд. Но есть ряд вопросов. Как бэкапить ? Где купить ? Цена ? Надёжен ли производитель ?
На всех ли ОС работает ? Как привязать несколько сервисов к одной карте ?
Когда это работает только в ИЕ — всё становится особенно грустно. С одной стороны у нас могут быть аппаратные крипто-процессоры, эллиптические кривые, защищённые контроллеры, а с другой — телеметрия майкрософт, сливающая данные гигабайтами хз куда.
Всё-таки 2ФА решения должны быть кроссплатформенными.

Посмотрел я на этот раздрай, и пришла мне в голову совершенно чумовая идея.

Встречайте :: Комбо-фаталити от Амина: OTP-in-PGP.
Впервые задействование PGP для двухфакторки я увидел на pgpru.com Но там для этого требовалось подписать некое случайное число и отправить подпись. Трабл в том, что для этого нужно делать обработку бинарного по своей внутренней сути пользовательского ввода, да ещё и довольно кривой внутренней структуры. Это более сложно в реализации и создаёт дополнительные риски нарваться на какую-нибудь хитрую уязвимость в парсерах / криптолибах / прочем.

Есть идея проще — попросить указать пользователя открытый PGP-ключ. После чего просто генерим на сервере некую случайную длинную строку (корректность символов которых мы может профильтровать простейшей регуляркой), криптуем её pgp-ключом пользователя, просим расшифровать и расшифрованное вставить в поле ввода. Можно как отсылать pgp-блок на почту, так и просто его показать прямо на странице. Есть ключ — раскриптовал и зашел, нет — ну значит нет. С почтой аутентификация аж тройная получается, если туда этот блок данных отсылать, а не просто его показывать на странице.

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

Да, это менее надёжно, чем аппаратный токен с неизвлекаемым ключом, зато гораздо проще, понятнее и дешевле. Знание о том, что такая аутентификация используется, никак не помогает злоумышленнику обойти такой 2ФА.

Я попробовал сделать такое на одном внутреннем сервисе — оно работает, и весьма зачётно.

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

Тут уместно вернуться к вопросу об атаках на понижение. Есть определённое удобство, когда онлайн-банк предлагает выбрать между разными методами подтверждения.
Варианты выбора между JaCarta, РуТокеном и аппаратным U2F — норм.
Между получением OTP-кода через PGP или подписанием строки криптовалютным ключом — тоже норм.
И даже между смс и обычной элеткропочтой — вполне.
Но выбор между СМС и аппаратным токеном — это полная дичь. Методы слишком различаются по своей силе, в таком случае токен теряет смысл как второй фактор, когда в качестве варианта есть гораздо более слабый метод.

Если тема окажется интересной — попробую наваять заметку о реализации.

Stay secure.

- комментарии
  1. На PGP несложно аппаратный токен приделать, достаточно купить Java-карту и залить туда OpenPGP апплет, который на гитхабе валяется от YubiKey. После чего оно начинает опознаваться обычным gpg через команды для смарт-карт.

  2. Amin:

    Это для совсем крутых параноиков. Но идея мне определённо нравится =)

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.