По мотивам сообщений о грядущем добровольно-принудительном переводе сервиса госуслуг на двухфакторную аутентификацию полагаю полезным дополнить историческую публикацию (2014 год) продаванов вредоносного ПО другой, тоже выдержанной (2018 год) статейкой-алиби тагоже блогосервиса.
Но сначала для посмеяться над дистанцией от «определения» до *правильного* ответа, процитирую историческую формулировку:
Двухфакторная аутентификация — это система доступа, основанная на двух «ключах»: одним вы владеете (телефон, на который приходит SMS с кодом), другой запоминаете (обычные логин и пароль).
Особенно занимательно данная цитата смотрится на фоне свидетельств об общеупотребительных (!) истинах из современной годной *детской* (!) литературы («Математика и криптография» Романа Душкина).
Коды в SMS небезопасны — рекомендуем пользоваться другими вариантами двухфакторной аутентификации
Почему SMS — не лучший выбор для двухфакторной аутентификации, и какие существуют альтернативы.
Что выбрать для двухфакторной аутентификации: SMS, приложение или YubiKey
За последние пару лет идея двухфакторной аутентификации, о которой так долго говорили гики, сильно продвинулась в массы. Однако до сих пор в большинстве случаев речь идет о двухфакторной аутентификации при помощи одноразовых паролей, приходящих в SMS. А это, к сожалению, не очень-то надежный вариант. Вот что может пойти не так:
- Пароль в SMS можно подсмотреть, если у вас включен показ уведомлений на экране блокировки.
- Даже если показ уведомлений отключен, можно извлечь SIM-карту из смартфона, установить в другой смартфон и принять SMS с паролем.
И-23: обратите внимание на то, как проводится мысль об инвариантности *смартфона*.
Прекраснее только отсутствие детализации закономерностей специальной дисциплины (удобство vs безопасность) на примере популярной практики выключения запроса PIN-кода.
- SMS с паролем может перехватить пробравшийся в смартфон троян.
- Также с помощью различных махинаций (убеждение, подкуп, сговор и так далее) можно заполучить новую SIM-карту с номером жертвы в салоне сотовой связи. Тогда SMS будут приходить на эту карту, а телефон жертвы просто не будет связываться с сетью.
- Наконец, SMS с паролем может быть перехвачена через фундаментальную уязвимость в протоколе SS7, по которому эти SMS передаются.
Надо заметить, что даже самый трудоемкий и высокотехнологичный из перечисленных методов перехвата пароля в SMS — с помощью взлома протокола SS7 — уже был использован на практике. Так что речь не о теоретической возможности возникновения неприятностей, а о вполне практической угрозе.
В общем, пароли в SMS — это не очень-то безопасно, а иногда даже и очень небезопасно. Поэтому есть смысл озаботиться поиском альтернативных вариантов двухэтапной аутентификации, о чем мы сегодня и поговорим.
Одноразовые коды в файле или на бумажке
Наиболее простая замена одноразовым паролям, присылаемым в SMS, — это те же самые одноразовые пароли, но заготовленные заранее. Это не самый плохой вариант, особенно для тех сервисов, в которых вам надо авторизовываться сравнительно редко. Собственно, даже для того же «Фейсбука» этот метод вполне может подойти, особенно в качестве резервного способа входа.
Работает это очень просто: по запросу сервис генерирует и показывает на экране десяток одноразовых кодов, которые в дальнейшем могут быть использованы для подтверждения входа в него. Дальше вы просто распечатываете или переписываете эти коды на бумагу и кладете в сейф. Или, что еще проще, сохраняете в зашифрованных записях в менеджере паролей.
В общем, не так важно, будете ли вы хранить эти коды на теплой ламповой бумаге или в бездушном цифровом виде — важно сохранить их так, чтобы они а) не потерялись и б) не могли быть украдены.
Приложения для двухфакторной аутентификации
У единожды сгенерированного набора одноразовых кодов есть один недостаток: рано или поздно он закончится, и вполне может так получиться, что вы останетесь без кода в самый неподходящий момент. Поэтому есть способ лучше: можно генерировать одноразовые коды на лету с помощью небольшого и, как правило, очень простого приложения — аутентификатора.
Как работают приложения-аутентификаторы
Работают приложения для двухфакторной аутентификации очень просто. Вот что придется сделать:
- устанавливаете на смартфон приложение для двухфакторной аутентификации;
- заходите в настройки безопасности сервиса, который среди опций для двухфакторной аутентификации предлагает использовать такие приложения;
- выбираете двухфакторную аутентификацию с помощью приложения;
- сервис покажет вам QR-код, который можно отсканировать прямо в 2FA-приложении;
- сканируете код приложением — и оно начинает каждые 30 секунд создавать новый одноразовый код.
Коды создаются на основе ключа, который известен только вам и серверу, а также текущего времени, округленного до 30 секунд. Поскольку обе составляющие одинаковы и у вас, и у сервиса, коды генерируются синхронно. Этот алгоритм называется OATH TOTP (Time-based One-time Password), и в подавляющем большинстве случаев используется именно он.
Также существует альтернатива — алгоритм OATH HOTP (HMAC-based One-time Password). В нем вместо текущего времени используется счетчик, увеличивающийся на 1 при каждом новом созданном коде. Но этот алгоритм редко встречается в реальности, поскольку при его использовании гораздо сложнее обеспечить синхронное создание кодов на стороне сервиса и приложения. Проще говоря, есть немалый риск, что в один не очень прекрасный момент счетчик собьется и ваш одноразовый пароль не сработает.
Так что можно считать OATH TOTP де-факто индустриальным стандартом (хотя формально это даже не стандарт, на чем создатели этого алгоритма очень настаивают в его описании).
Совместимость приложений для двухфакторной аутентификации и сервисов
Подавляющее большинство приложений для двухфакторной аутентификации работает по одному и тому же алгоритму, так что для всех сервисов, которые поддерживают аутентификаторы, можно использовать любое из них — какое вам больше нравится.
Как и в любом добротном правиле, в этом тоже есть определенное количество исключений. Некоторые сервисы по каким-то причинам, ведомым только им одним, предпочитают делать свои собственные приложения для двухфакторной аутентификации, которые работают только с ними. Более того, сами сервисы не работают ни с какими другими приложениями, кроме своих собственных.
Особенно это распространено среди крупных издателей компьютерных игр — например, существуют несовместимые со сторонними сервисами приложения Blizzard Authenticator, Steam Mobile с встроенным аутентификатором Steam Guard, Wargaming Auth и так далее. Для этих сервисов придется ставить именно эти приложения.
Также по этому странному пути пошла Adobe, разработавшая Adobe Authenticator, который работает только с аккаунтами AdobeID. Но при этом вы можете использовать для защиты AdobeID и другие аутентификаторы, так что вообще непонятно, ради чего было городить огород.
Так или иначе, большинство нормальных ИТ-компаний не ограничивает пользователей в выборе 2FA-приложения. И даже если по каким-то соображениям им хочется контролировать этот процесс и создать свое приложение, то чаще всего они позволяют защищать с его помощью не только «свои» аккаунты, но и учетные записи сторонних сервисов.
Поэтому просто выбирайте приложение-аутентификатор, которое вам больше нравится по набору дополнительных функций — оно будет работать с большинством сервисов, которые вообще поддерживают 2FA-приложения.
Лучшие приложения для двухфакторной аутентификации
Выбор 2FA-приложений на удивление велик: поиск по запросу «authenticator» в Google Play или Apple App Store выдает не один десяток результатов. Мы не советуем устанавливать первое попавшееся приложение — это может быть небезопасно, ведь, по сути, вы собираетесь доверить ему ключи от своих аккаунтов (оно не будет знать ваши пароли, конечно, но ведь 2FA вы добавляете именно потому, что пароли имеют свойство утекать). В общем, стоит выбирать из приложений, созданных крупными и уважаемыми разработчиками.
Несмотря на то что базовая функция у всех этих приложений одна и та же — создание одноразовых кодов по одному и тому же алгоритму, некоторые аутентификаторы обладают дополнительными функциями или особенностями интерфейса, которые могут показаться вам удобными. Перечислим несколько самых интересных вариантов.
1. Google Authenticator
Поддерживаемые платформы: Android, iOS
Как отмечают буквально все публикации, Google Authenticator — это самое простое в использовании из всех существующих приложений для двухфакторной аутентификации. У него даже настроек нет. Все, что можно сделать, — это добавить новый токен (так называется генератор кодов для отдельного аккаунта) или удалить один из имеющихся. А чтобы скопировать код в буфер обмена, достаточно коснуться его пальцем на сенсорном экране смартфона или планшета. Все!
Однако у такой простоты есть и недостаток: если вам что-то не нравится в интерфейсе или хочется от аутентификатора чего-то большего — придется устанавливать другое приложение.
+ Очень просто использовать.
2. Duo Mobile
Поддерживаемые платформы: Android, iOS
Duo Mobile также крайне прост в использовании, минималистичен и лишен дополнительных настроек. По сравнению с Google Authenticator у него есть одно преимущество: по умолчанию Duo Mobile скрывает коды — чтобы увидеть код, надо нажать на конкретный токен. Если вы, как и я, испытываете дискомфорт каждый раз, когда открываете аутентификатор и показываете всем окружающим кучу кодов от всех своих аккаунтов сразу, то вам эта особенность Duo Mobile наверняка понравится.
+ По умолчанию скрывает коды.
3. Microsoft Authenticator
Поддерживаемые платформы: Android, iOS
В Microsoft тоже не стали усложнять и сделали свой аутентификатор на вид очень минималистичным. Но при этом Microsoft Authenticator заметно функциональнее, чем Google Authenticator. Во-первых, хоть по умолчанию все коды показываются, но каждый из токенов можно отдельно настроить так, чтобы при запуске приложения код был скрыт.
Во-вторых, Microsoft Authenticator упрощает вход в аккаунты Microsoft. В этом случае после ввода пароля достаточно будет нажать в приложении кнопку подтверждения входа — и все, можно даже не вводить одноразовый код.
+ Можно настроить, чтобы коды скрывались.
+ Дополнительные возможности для входа в аккаунты Microsoft.
4. FreeOTP
Поддерживаемые платформы: Android, iOS
Есть четыре причины, по которым вам может понравиться этот аутентификатор, разработанный Red Hat. Во-первых, это ваш выбор, если вы любите программное обеспечение с открытым кодом. Во-вторых, это самое маленькое приложение из всех рассматриваемых — версия для iOS занимает всего 750 Кбайт. Для сравнения: минималистичный Google Authenticator занимает почти 14 Мбайт, а приложение Authy, о котором мы поговорим ниже, — аж 44 Мбайта.
В-третьих, по умолчанию приложение скрывает коды и показывает их только после касания. Наконец, в-четвертых, FreeOTP позволяет максимально гибко конфигурировать токены вручную, если вам это зачем-нибудь нужно. Разумеется, обычный способ создания токена с помощью сканирования QR-кода тоже поддерживается.
+ По умолчанию скрывает коды.
+ Приложение занимает всего 700 Кбайт.
+ Открытый код.
+ Максимум настроек при создании токена вручную.
5. Authy
Поддерживаемые платформы: Android, iOS, Windows, macOS, Chrome
Самое навороченное из приложений для двухфакторной аутентификации, основным достоинством которого является то, что все токены хранятся в облаке. Это позволяет получить доступ к токенам с любого из ваших устройств. Заодно это упрощает переезд на новые устройства — не придется заново активировать 2FA в каждом сервисе, можно продолжить пользоваться существующими токенами.
В облаке токены зашифрованы ключом, который создается на основе заданного пользователем пароля, — то есть данные хранятся безопасно, и украсть их будет нелегко. Также можно установить ПИН-код на вход в приложение — или защитить его отпечатком пальца, если ваш смартфон оснащен соответствующим сканером.
Основной недостаток Authy состоит в том, что приложение с ходу требует завести аккаунт, привязанный к вашему телефонному номеру, — без этого просто не получится начать с ним работать.
+ Токены хранятся в облаке, что позволяет использовать их на всех своих устройствах.
+ По той же причине очень удобно переезжать на новое устройство.
+ Вход в приложение защищен PIN-кодом или отпечатком пальца.
+ На экране показывается код только для последнего использованного токена.
+ В отличие от остальных приложений, поддерживает не только Android и iOS, но и Windows, macOS и Chrome.
− Требуется зарегистрироваться в Authy, используя номер телефона, — без этого приложение не работает.
6. «Яндекс.Ключ»
Поддерживаемые платформы: Android, iOS
На мой взгляд, по концепции «Яндекс.Ключ» — это самое удачное из существующих приложений для двухфакторной аутентификации. С одной стороны, оно не требует с ходу регистрироваться — можно начать им пользоваться с той же легкостью, как и Google Authenticator. С другой стороны, в нем есть несколько дополнительных возможностей, которые открываются тем, кто не поленится зайти в настройки.
Во-первых, «Яндекс.Ключ» можно «запереть» на PIN-код или отпечаток пальца. Во-вторых, можно создать в облаке «Яндекса» резервную копию токенов, защищенную паролем (а вот на этом этапе уже придется указать номер телефона), и восстановить ее на любом из используемых вами устройств. Точно так же можно будет перенести токены на новое устройство, когда понадобится переезжать.
Получается, что «Яндекс.Ключ» сочетает в себе простоту Google Authenticator и расширенную функциональность Authy — в зависимости от того, что вы предпочитаете. Единственный недостаток приложения — не вполне удобный для использования с большим количеством токенов интерфейс.
+ Минимализм на старте, расширенная функциональность доступна через настройки.
+ Создание резервных копий токенов в облаке для использования на нескольких устройствах и переезда на новые.
+ Вход в приложение защищен PIN-кодом или отпечатком пальца.
+ На экране показывается код только для последнего использованного токена.
+ Заменяет постоянный пароль к аккаунту «Яндекса».
− При большом количестве токенов не очень удобно искать нужный.
«Железные» аутентификаторы FIDO U2F: YubiKey и все-все-все
Если приложение, генерирующее одноразовые коды, кажется вам слишком эфемерным способом защитить свои аккаунты, и хочется чего-то более постоянного, надежного и материального — буквально запереть аккаунт на ключ и положить его в карман, — то у меня есть для вас хорошая новость: такой вариант также существует. Это аппаратные токены стандарта U2F (Universal 2nd Factor), созданного FIDO Alliance.
Как работают токены FIDO U2F
Аппаратные U2F-токены очень полюбились специалистам по безопасности — в первую очередь потому, что с точки зрения пользователя они работают очень просто. Для начала работы достаточно подключить U2F-токен к вашему устройству и зарегистрировать его в совместимом сервисе, причем делается это буквально в пару кликов.
Впоследствии при необходимости подтвердить вход в этот сервис нужно будет подключить U2F-токен к тому устройству, с которого вы входите, и нажать на токене кнопку (в некоторых устройствах — ввести PIN или приложить палец к сканеру). Все — никаких сложных настроек, ввода длинных последовательностей случайных символов и прочих танцев с бубном, которые обычно все себе представляют при упоминании слова «криптография».
При этом «под капотом» все устроено очень умно и криптографически надежно: при регистрации токена на сервисе создается пара криптографических ключей — приватный и публичный. Публичный сохраняется на сервере, а приватный хранится в защищенном хранилище Secure Element, которое является сердцем U2F-токена, — и этот ключ никогда не покидает устройство.
Приватный ключ используется для того, чтобы зашифровать подтверждение входа, которое передается на сервер и может быть расшифровано с помощью публичного ключа. Если кто-то от вашего имени попытается передать подтверждение входа, зашифрованное неправильным приватным ключом, то при расшифровке с помощью известного сервису публичного ключа вместо подтверждения получится бессмыслица, и сервис не пустит его в аккаунт.
И-23: О чудо! Внезапное и даже почти правильное описание традиционного механизма публичного/приватного (в русской терминологической традиции — «закрытого») ключа.
Не ждал…
Но до постижения логики стандарта X.509 ещё пилить и пилить…
Какими бывают U2F-устройства
Наиболее известный и распространенный пример U2F — это «ключи» YubiKey, которые производит компания Yubico. Собственно, она и стояла у истоков этого стандарта, но предпочла сделать его открытым, для чего и был создан FIDO Alliance. А поскольку стандарт открытый, вы не ограничены в выборе: U2F-совместимые устройства производят и продают разные компании — в онлайн-магазинах можно найти множество разнообразных моделей.
Например, Google недавно представила свой комплект аппаратных аутентификаторов Google Titan Security Keys. На самом деле это ключи производства Feitian Technologies (второй по популярности производитель U2F-токенов после Yubico), для которых в Google написали собственную прошивку.
Разумеется, все аппаратные аутентификаторы, совместимые со стандартом U2F, будут с одинаковым успехом работать со всеми сервисами, которые также с этим стандартом совместимы. Однако у разных моделей есть несколько важных различий, и самое важное из них — это интерфейсы, которыми оборудован «ключ». От этого напрямую зависит, с какими устройствами он сможет работать:
USB — для подключения к компьютерам (Windows, Mac или Linux — неважно, «ключи» работают без установки каких-либо драйверов). Помимо обычного USB-A бывают «ключи» с USB-C.
NFC — необходим для использования со смартфонами и планшетами на Android.
Bluetooth — понадобится на тех мобильных устройствах, в которых нет NFC. К примеру, аутентификатор с Bluetooth все еще нужен владельцам iPhone: несмотря на то, что в iOS уже разрешили приложениям использовать NFC (до 2018 года это было позволено только Apple Pay), разработчики большинства совместимых с U2F приложений еще не воспользовались этой возможностью. У Bluetooth-аутентификаторов есть пара минусов: во-первых, их нужно заряжать, а во-вторых, их подключение занимает гораздо больше времени.
В базовых моделях U2F-токенов обычно есть только поддержка собственно U2F — такой ключ обойдется в $10–20. Есть устройства подороже ($20–50), которые заодно умеют работать в качестве смарт-карты, генерировать одноразовые пароли (в том числе OATH TOTP и HOTP), генерировать и хранить ключи PGP-шифрования, могут использоваться для входа в Windows, macOS и Linux и так далее.
И-23: обратите внимание на то, как проводится мысль о том, что *правильное* решение задачи (публичный/приватный ключ) не работает без приобретения отдельного… гаджета.
О знании… скажем так, «особенностей» поддержки оными аппаратными устройствами платформ, отличных от самой распространённой ОС (с коммерчески-успешными спутниками) скромно умолчим.
Что же выбрать: SMS, приложение или YubiKey?
Универсального ответа на этот вопрос не существует — для разных сервисов можно использовать разные варианты двухфакторной аутентификации в различных сочетаниях. Например, наиболее важные аккаунты (скажем, вашу основную почту, к которой привязаны остальные учетные записи) стоит защитить по максимуму — запереть на «железный» U2F-токен и запретить любые другие опции 2FA. Так можно быть уверенным, что никто и никогда не получит доступ к аккаунту без этого токена.
Хороший вариант — привязать к аккаунту два «ключа», как это делается с ключами от автомобиля: один всегда с собой, а другой лежит в надежном месте — на случай, если первый потеряется. При этом «ключи» могут быть разного типа: скажем, приложение-аутентификатор на смартфоне в качестве основного и U2F-токен или листочек с одноразовыми паролями, лежащий в сейфе, в качестве резервного средства.
Так или иначе, главный совет — по возможности избегать использования одноразовых паролей в SMS. Правда, получится это не всегда: например, финансовые сервисы в силу своей консервативности продолжают использовать SMS и крайне редко позволяют пользоваться чем-либо еще.
Комментарии
И эти все приложения ни разу не видят информацию о тебе 🤣
Не думаю, что FreeOTP видит пользовательскую информацию.
//Или, что еще проще, сохраняете в зашифрованных записях в менеджере паролей.
Ай лайк ит!
Фундаментальной… особенности механизма данный подход не решает.
А мне и АНБ нравиццо. Слить сразу все пароли оптом - это оч хорошо.
А не проще отказаться от этих аутентификаций вообще?
Автор не заметил еще одну опасность - снег и травмы от ходьбы по нему. Забыть пароль после сотрясения мозга или его ушиба весьма легко.
ПИНкод в телефоне хорош для офисного работника. А когда надо позвонить родственникам получившего травму рабочего - он очень мешает. И вернуть найденный телефон владельцу, если в нем пинкод - тоже сложнее, так как невозможно позвонить его родным или на работу, и договориться о возврате.
Оно, конечно, проще. Но не всем хочется ходить в то же банковское отделение для каждого перевода. А ещё меньшему количеству народа хочется, чтобы потерянный телефон давал нашедшему неограниченный доступ к личным финансам.
Большинство сервисов предлагают функцию восстановления паролей. Но вообще действительно нужно озаботится о хранении пароля вне головы.
Я использую менеджер паролей, для каждого сервиса генерирую отдельный длинный пароль. База данных паролей многократно резервируется. То есть мне нужно помнить один-единственный пароль. На случай, если я его забуду или помру, в сейфе лежит запечатанный конверт с завещанием, этим самым мастер-паролем и подробной инструкцией.
Уточнить домашний телефон можно в отделе кадров. У меня на работе можно сообщить в отдел кадров телефон, по которому следует звонить в случае травмы и прочего. Ну и если от рабочего остался хотя бы палец, то можно попробовать разблокировать по отпечатку
На большинстве современных смартфонов можно настроить произвольный текст на экране блокировки. В том числе и вида "нашедшему звонить по номеру хххххххх".
Здесь самый вкусный вопрос в ресурсоёмкости синхронизации дерева резервных копий (ибо пароли временами меняются).
Я это решил синхронизацей с собственным облаком на базе Nextcloud. Одна из точек синхронизации делает резервные копии на случай удаления или порчи файла.
Как у Вас все сложно!
А если телефон только для звонков, а все остальное с домашнего компа, насколько все проще!
Да и при утере, аппарат за 1500р вернут вероятнее, чем за 50тыс.
Статистически СМС обечпечивает необходимую защиту. Перехваты - это надо специально за кем-то охотиться, это целый комплекс мер. Трояны - ну да, это общая для компьютеров угроза. Но и при абсолютной защищенности устройств можно же самого человека просто поймать и заставить сделать нужное, все что угодно, кроме личного похода в офис банка, если куш того стоит с точки зрения злоумышленника.
Технологически SMS — это делегирование ответственности в нафиг, с последующим эталонно-некорррупционным комплексом мероприятий по оптимизации *внешней* (!) системы под симулирующие адекватность критерии делегированной функции.
Наводящие вопросы:
1. Допустимое [согласно Изначальному проекту] время доставки SMS?
2. Оно же, но применительно к делегированной функции.
Ну и отдельно, особо и сугубо (слава руководству господина Фокса!) — надлежащее в части полноты тестирование отработки исключений повторной отправки запросов при встрече с рудиментами п.1.
Проблема с СМС паролями - это вера как пользователей, так и технических специалистов в то, что это универсальное решение для обеспечения 100% безопасности. Если относиться к ним как к тому, чем они и являются - одним из дополнительных способов усложнить злоумышленникам доступ к системе, то всё с ними в порядке. Хороший, регулярно сменяемый пароль + СМС подтверждение это в среднем лучше чем просто хороший, регулярно сменяемый пароль.
Ситуация со сторонними аутентификаторами ровно такая же как с СМС - как только администраторы поверят, что это универсальная защита, они превратятся в ещё одну из проблем безопасности, а не их решение. Усугубляется всё тем, что рядовые пользователи системы обычно плохо разбираются в логике работы того, чем пользуются, а также ленятся выполнять простейшие действия, если делать это надо достаточно регулярно. Ну и да, администраторы в этом плане очень часто не очень далеко ушли от своих пользователей.
Проблема апологетов «одним из дополнительных способов усложнить злоумышленникам доступ к системе» в том, что страшно далеки они от народа эксплоатационных реалий.
И только *личный* (!) опыт эксплоатации системы с жалкими сотнями «регулярно сменяемых» паролей (когда издержки на оное действо способны скушать все 146% рабочего времени) способен наставить их на путь истинный.
Которая не грозит пользователям кнопочных телефонов с тарифом без интернета..
Вы отстали от жизни.
На такие телефоны уже давно во славу оптимизации суют избыточное железо и… тот же самый андроид. ☹
Как разница, если доступа к интернету нет? Я не большой специалист, но к примеру у Нокиа 3310 ОС Series 30+ я так понимаю это не Андройд.
О любви ОпСОСов к «ознакомительному» подключению разного рода услуг помните?
В пакете с модными опциями халявного доступа к мессенджерам с соцсетями…
ЗЫ: 3310 — новодел! Наш выбор — 1100!!!
Хоть к чему, ещё раз есть тарифы без интернета. Есть многие кнопочные телефоны, без интернета. Допы мне к примеру не подключают. Вот к примеру 10 лучших кнопочных телефонов без камеры и интернета в 2022 г.
Читал я статью об этом, как тестировали целую кучу. То что вы говорите и плюс ещё и отправку инфы о вас практикуют далеко не все такие телефоны.
Древняя Нокия 1100(с фонариком) такое точно не умеет
RSA.
Вроде был прецедент, что они, оказывается, хранят копии всех приватных ключей токенов клиентов (мол для удобства восстановления клиентами конечно))
И как-то раз у них всю эту базу увели. Они потом что-то около года скрывали факт этой утечки.
Ну, когда идет взлом или утечка на сервере, любая система аутентификации "пасует"
А вот, с точки зрения безопасности клиента, RSA SecureID повыгоднее смотрится. Потенциальному взломщику надо спереть либо сам токен, либо набор "аварийных" ключей (который можно просто сразу уничтожить, для пущего спокойствия, доступ все-равно восстанавливается, просто дольше и сложнее выйдет).
ps: Есть, правда, опасность, связанная с подглядыванием. Зная, какие ключи вводил пользователь в определенные моменты времени, можно попробовать, по известным значениям функции, выявить и ее саму, но сложно.
В правильном случае (когда закрытый ключ *только* (!) у клиента) утечка на стороне сервера не носит фатального характера.
Только такой подход режет практически всю хомячковую базу (тех пользователей, которым впариваемый сервис по-хорошему ненужен).
За давностью лет могу путать, лучше прогуглить это. Но по памяти было что-то такое:
1) Вы покупаете токен в котором прошиты приватный и публичный ключ.
2) Приватный ключ не должен где-либо храниться, обрабатываться или передаваться вне токена.
3) Когда вы что-то подписываете - этот контент уходит в токен, токен внутри себя подписывает данные приватным ключем и отдает наружу токена готовую подпись.
4) Публичный ключ из токена естественно доступен и его можно регистрировать в аккаунтах и т.п.
5) Вы думали, что приватный ключ есть только у вас, но, как оказалось, RSA его себе забэкапили для ФБР, АНБ и т.п.(может где-то мелким шрифтом и описано что они так делают для целей восстановления после утери - точно не помню на самом деле, но как по мне это явно нонсенс так делать).
6) Теперь эти ключи есть и у неких злоумышленников, которые их увели у RSA.
Выводы - как и с псевдошвейцарскими криптомашинками - ничего такого не использовать, применять опенсорс с хорошей проверкой исходников специалистами, как например, для TrueCrypt делалось. Все, что коммерческое и зарегистрировано в какой-либо юрисдикции - наверняка содержит бэкдоры и сливает ключи спецслужбам.
Т.е. как дополнительный фактор можно использовать, но не панацея.
Однако с «гуглингом» *правильного* (!) ответа на сколько-нибудь нетривиальный вопрос… возможны сюрпризы.
В опять же идеально-правильном случае:
1. Покупается специальной устройство типа «токен», с некоторым объёмом памяти и микросхемой реализующей необходимые функции;
2. Пользователь формирует закрытый ключ;
3. Закрытый ключ в комплекте с приватным ключом (в предположении использования стандарта X.509) записывается на токен. Для чего даже предусмотрен специальный формат контейнера (НЯП PKCS#12, с комплектом критики, который я до физического обеспечения не разворачивал).
C буржуями понятно, я это в принципе про алгоритм аутентификации.
В том смысле, что SecureID смотрится надежнее этой, как по мне, очень странной истории с "асимметричным шифрованием"
Там есть свои слабости, выше упомянутые, но, в принципе, достаточно "накинуть" сверху еще пару функций, чтобы даже взлом посредством подглядывания за пользователем стал возможен только теоретически. Скажем, использовать не один алгоритм генерации, а тысчонку-другую, распределяемую случайным образом (заодно, ограничив ущерб при взломе), плюс, "заложить", например, временные сдвиги генерирующего алгоритма.
Во взрослой модели удостоверяющему центру не положено (и не нужно) доступа к закрытому ключу абонента.
Не понял, а как, в таком случае, происходит проверка подлинности ключа? Как замок может "не знать", каким ключом он открывается?
Аналогия не вполне корректна.
А рамках *базовой* модели (по публичному ключу) пара закрытый/публичный ключ создаётся пользователем.
С последующим распространением *только* публичного ключа имже.
Модель стандарта X.509 несколько сложнее.
Там пользователь формирует свой закрытый ключ.
Потом на основании этого закрытого ключа создаёт запрос на подпись сертификата.
И это *запрос* (но ни в коем случае НЕ ЗАКРЫТЫЙ КЛЮЧ!!!) отправляет в Удостоверяющий центр для издания сертификата (в данной модели являющегося аналогом *публичного* ключа базовой модели).
Ну, и что от этого меняется? Кроме того, что функцию ключа начинает выполнять сертификат? Да, то, что пользователь задает какой-то собственный пароль (назовем так, чтобы не путаться с двумя "ключами") несколько повышает уровень защиты, но в любом случае, и пользовательский пароль и сертификат и алгоритм создания сертификата серверу известны, иначе вся эта конструкция просто не будет работать.
Ни «пользовательский пароль», ни закрытый ключ пользователя никому, кроме пользователя на известны.
Зачитайте хотя бы приличные *детские* книжки!!!
Как они могут быть не известны никому, кроме пользователя, если при их участии происходит проверка подлинности?
Это то, с чего я начал, и то, что вы обозвали "некорректной аналогией" А это не некорректная аналогия, это базовый принцип работы системы авторизации. Поделать с которым вы ничего не можете: замок, открываемый строго определенным ключом, должен иметь соответствующую, строго определенную, конфигурацию. Это не меняется, сколько бы сложных функций формирования ключа вы сверху не "навалили"
Не вдаваясь в особенности реализации:
С помощью *закрытого* ключа пользователь шифрует сообщение.
Расшифровка которого осуществляется сервером с помощью открытого ключа пользователя.
Зачем может серверу потребоваться закрытый ключ *пользователя*?
Чиво, бл%#ь? (c)
Шифруют одним ключом, расшифровывают другим? Это как?
Это называется асимметричная криптография. Весь современный веб (https), электронные подписи и банковская криптография на этом основаны.
На самом деле тут есть и большая опасность, как только произойдет прорыв в квантовых компьютерах - все это стремительно превратится в тыкву, вернемся к бумажному документообороту, походам в банк, забудем про банкоматы и т.п. В общем, надежда что успеют постквантовую криптографию придумать.
Однако с наиболее распространённым сценарием использования протокола HTTPS есть интересный нюанс.
ЗЫ: Ну и просто позвольте напомнить Вам аналогию с востребованнейшей в течение многих веков задачей изобретения Вечного двигателя.
Это даже продаваны вредоносного ПО знают (я, кстати, несколько ошибся в описании алгоритма, но на вывод данная конкретная ошибка не влияет):
У вас путаница в понятийном аппарате, откуда непонимание.
Ключом доступа, в данном случае, выступает функция, связывающая открытый и закрытый "ключи"
upd: Точнее, даже не так: ключ, на самом деле, один, просто из него, посредством некоторой функции, "изготавливают" два. И сервер, очевидно, "знает" их оба.
upd2: Кстати, само использование "закрытого ключа" затея сомнительная, безопасность на клиенте, по определению, хуже, чем на сервере, да плюс передача. Старый-добрый "пароль в конверте" понадежнее будет. ;)
Это противозаконно, есть подозрение, что за такое положен отзыв лицензии УЦ
Специальная дисциплина (удобство vs безопасность) закончилась с появлением openssh. Сегодня каждый недоучка делает scp и это убодно. И хрен декодируешь. Так что нужно и удобно и безопасно.
Приснопамятную историю с патчиком в OpenBSD успели запамятовать?..
А если вместо смс пуш в банковское приложение?
А перевести модные псевдонимы?..
ЗЫ: Наводящий вопрос: банковое приложение как аутентифицируется?
ПИН кодом и пальцем
Это UI, и он… недостаточен для выводов относительно реализации.
Конечно. Я никаких выводов и не делаю.
Исходники банковского приложения я, разумеется, не видел. Хотя подозреваю, что там используются стандартные библиотеки для работы со встроенным сканером отпечатков пальца, через драйвера, исходники, которых я тоже не смотрел. Более того, код ревью операционки я тоже не проводил. Подозреваю, что там много чего интересного зашито.
смс хороши, когда ты дома. А как только хрен знает где - могут не доходить. А если в этом хрен знает где еще и телефон пролюбить - труба.
Пароль при необходимости можно выучить. А вот где взять новую симку, если этот оператор в текущем регионе/стране вообще отсутствует - вот это проблема. Поэтому всегда приходится пачку нала возить. Ибо вероятность: то смс нету, то карту подозрительно заблокируют совершенно ненулевая.
Однако, строго говоря, тут должно напомнить о том, что как минимум некоторые ростовщики дополнительно привязываются к идентификатору конкретной SIM-карты (и, соответственно, в случае восстановления номера на другой SIM-карте необходимо подтвердить изменения личным посещением офиса).
Это да, нет сотовой вышки любимого опсоса - и все, денег не заплатить никуда. В праздники так попал....
Страницы