двухфакторной аутентификации blockchain зачем она нужна
Переходите к безопасной 2FA на блокчейне
СМС-сообщения — популярнейший способ двухфакторной аутентификации (2FA). Ее используют банки, электронные и крипто-кошельки, почтовые ящики и всяческие сервисы; число пользователей метода приближается к 100%.
У меня такой расклад событий вызывает негодование, ведь этот метод небезопасный. Переназначать номер с одной SIM-карты на другую стали еще в начале мобильной эры — так восстанавливают номер при потере симки. “Специалисты по отъему цифровых денег” осознали: опцию «перезаписи симки» можно использовать в мошеннических схемах. Ведь тот, кто контролирует сим-карту, может управлять и чужим онлайн-банкингом, и электронными кошельками, и даже криптовалютой. А завладеть номером другого лица можно через подкуп сотрудника телекома, с помощью обмана или поддельных документов.
Раскрыты тысячи эпизодов SIM-свопинга — так назвали эту схему мошенничества. Масштабы бедствия говорят о том, что скоро мир откажется от 2FA по СМС. Но этого не происходит — в исследовании рассказывают, что выбирают метод 2FA не пользователи, а владельцы сервисов.
Мы предлагаем использовать безопасный метод 2FA с доставкой одноразовых кодов через блокчейн, и расскажем, как владельцу сервиса его подключить.
Счет идет на миллионы
В 2019 году мошенничество SIM-свопингом выросло на 63% по данным лондонской полиции, а “средний чек” злоумышленника — 4,000 GBP. Статистики в России я не нашел, однако предполагаю, что она еще хуже.
SIM-свопинг используется для кражи популярных аккаунтов Twitter, Instagram, Facebook, VK, банковских аккаунтов, а недавно добрались и до криптовалют — сообщает газета Таймс со слов биткоин-предпринимателя Джоби Уикса. Громкие дела о краже криптовалют с помощью SIM-свопинга всплывают в прессе с 2016 года; на 2019-й пришелся настоящий пик.
Фото Джоэла Ортиза на пресс-конференции в университете. Спустя два года он будет задержан за кибермошенничество.
Принцип работы SIM-свопинга
«Свопинг» — значит обмен. Во всех подобных схемах преступники присваивают себе телефонный номер жертвы, обычно через перевыпуск SIM-карты, и пользуются им для сброса пароля. Типичный SIM-свопинг в теории выглядит так:
Теперь все СМС будут получать злоумышленники, а владелец телефона ничего не сможет с этим сделать — он за границей. А дальше злодеи получают доступ ко всем аккаунтам жертвы и при желании меняют пароли.
Шансы вернуть украденное
Банки иногда идут навстречу жертвам и отзывают переводы с их счетов. Поэтому вернуть фиатные деньги удается, даже если преступник не найден. Но с криптовалютными кошельками все сложнее — и технически, и законодательно. Пока ни одна биржа/кошелек не выплатили компенсации жертвам свопинга.
Пока ни у одного государства нет рабочих схем, чтобы законодательно защитить владельцев криптовалют. Застраховать свой капитал или получить компенсацию за его потерю невозможно. Поэтому предотвратить свопинг-атаку проще, чем бороться с ее последствиями. Самый очевидный способ — использовать более надежный «второй фактор» для 2FA.
SIM-свопинг — не единственная проблема 2FA через СМС
Коды подтверждения в СМС небезопасны и с технической точки зрения. Сообщения можно перехватить из-за неустранимых уязвимостей в сигнальной системе Signaling System 7 (SS7). 2FA по SMS официально признана небезопасной (Национальный институт стандартов и технологий США говорит об этом в своем Руководстве по цифровой аутентификации).
При этом наличие 2FA часто внушает пользователю чувство ложной безопасности, и он выбирает более простой пароль. Поэтому такая аутентификация не затрудняет, а облегчает доступ злоумышленника к аккаунту.
А еще нередко СМС приходят с большой задержкой или не приходят совсем.
Другие способы 2FA
Разумеется, на смартфонах и СМС свет клином не сошелся. Есть и другие способы 2FA. Например, одноразовые TAN-коды: способ примитивный, но рабочий — он до сих пор используется в некоторых банках. Есть системы с применением биометрических данных: отпечатков пальцев, сканов сетчатки. Еще один вариант, который кажется разумным компромиссом по удобству, надежности и цене — специальные приложения для 2FA: RSA Token, Google Authenticator. А еще есть физические ключи и другие методы.
В теории все выглядит логичным и надежным. Но на практике у современных 2FA-решений есть проблемы, и из-за них реальность отличается от ожиданий.
Согласно исследованию, использование 2FA является неудобством в принципе, а популярность 2FA по СМС объясняют “меньшим неудобством по сравнению с другими методами” — получение одноразовых кодов понятно для пользователя.
Многие способы 2FA пользователи связывают со страхом, что доступ будет утерян. Физический ключ или список TAN-паролей можно потерять или их могут украсть. У меня лично есть негативный опыт использования Google Authenticator. Первый смартфон с этим приложением у меня сломался — оцените мои труды по восстановлению доступа к аккаунтам. Другая проблема — переход на новое устройство. Google Authenticator не имеет возможности экспорта из-за соображений безопасности (если ключи можно экспортировать, какая тут безопасность?). Один раз я переносил ключи вручную, а дальше решил, что проще оставлять старый смартфон в коробке на полке.
Метод 2FA должен быть:
Используйте 2FA на блокчейне
Для пользователя 2FA на блокчейне выглядит так же, как и получение одноразовых кодов по СМС. Отличие только в канале доставки. Способ получения 2FA-кода зависит от того, что предлагает блокчейн. В нашем проекте (информация есть в моем профиле) это Web-приложение, Tor, iOS, Android, Linux, Windows, MacOS.
Сервис генерирует одноразовый код и посылает его в мессенджер на блокчейне. Дальше — по классике: пользователь вводит полученный код в интерфейсе сервиса и авторизуется.
В статье Как работает децентрализованный мессенджер на блокчейне я написал, что блокчейн обеспечивает безопасность и приватность передачи сообщений. По вопросу отправки кодов 2FA я выделю:
Аккаунт в блокчейн-мессенджере для получения кодов пользователь получает за секунду — для входа используется только пассфраза. Поэтому и способы применения могут быть разными: можно использовать один аккаунт для получения кодов для всех сервисов, а можно для каждого сервиса создать отдельный аккаунт.
Есть и неудобство — аккаунт должен иметь хотя бы одну транзакцию. Для того, чтобы пользователь получил шифрованное сообщение с кодом, нужно знать его публичный ключ, а он появляется в блокчейне только с первой транзакцией. Мы выкрутились так: дали возможность получить в кошельке бесплатные токены. Однако более правильное решение — именовать аккаунт публичным ключом. (Для сравнения у нас номер аккаунта U1467838112172792705 является производным публичного ключа cc1ca549413b942029c4742a6e6ed69767c325f8d989f7e4b71ad82a164c2ada. Для мессенджера это удобнее и читабельнее, а вот для системы отправки 2FA-кодов — ограничение). Думаю, в будущем кто-нибудь сделает такое решение и переведет “Удобство и доступность” в зеленую зону.
Цена отправки 2FA-кода реально низкая — 0.001 ADM, сейчас это 0.00001 USD. Опять же, можно поднять свой блокчейн и сделать цену нулевой.
Как подключить 2FA на блокчейне к вашему сервису
Надеюсь, я смог заинтересовать нескольких читателей, чтобы добавить блокчейн-авторизацию на их сервисы.
Я расскажу как это сделать на примере нашего мессенджера, а по аналогии вы можете использовать и другой блокчейн. В демо-приложении 2FA мы используем postgresql10 для хранения информации об аккаунтах.
Создание аккаунта в блокчейне — это генерация приватного ключа, публичного ключа, и производного от него адреса аккаунта.
Сначала генерируется пассфраза BIP39, из нее считается SHA-256-хэш. Хэш используется для генерации приватного ключа ks и публичного ключа kp. Из публичного ключа тем же SHA-256 с инверсией получаем адрес в блокчейне.
Если вы хотите отправлять коды 2FA каждый раз с нового аккаунта, код для создания аккаунта нужно будет добавить на сервер:
В демо-приложении мы упростили — создали один аккаунт в веб-приложении, и отправляем коды с него. В большинстве случаев это удобнее и пользователю: он знает, что сервис отправляет 2FA-коды с конкретного аккаунта, и может его именовать.
2 Генерация кодов 2FA
Код 2FA нужно генерировать для каждого входа пользователя. Мы используем библиотеку speakeasy, но вы можете выбрать любую другую.
Проверка валидности кода 2FA, введенного пользователем:
3 Отправка кода 2FA
Для отправки 2FA-кода можно использовать API узла блокчейна, библиотеку JS API или консоль. В этом примере мы используем консоль — это Command Line Interface, утилита, которая упрощает взаимодействие с блокчейном. Чтобы отправить сообщение с 2FA-кодом, нужно использовать команду send message консоли.
Альтернативный способ отправки сообщений — использовать метод send в JS API library.
4 Интерфейс пользователя
Пользователю нужно дать возможность ввода кода 2FA, это можно сделать различными способами в зависимости от платформы вашего приложения. В нашем примере это Vue.
Исходный код демонстрационного приложения двухфакторной авторизации на блокчейне можно посмотреть в GitHub. В Readme есть ссылка на Live demo, чтобы попробовать.
Двухфакторная аутентификация: что это и зачем оно нужно?
Мы решили посвятить двухфакторной аутентификации отдельную статью и рассказать о том, что это такое, как она работает и почему ее стоит использовать.
Двухфакторная аутентификация — тема, которой мы так или иначе касаемся во многих наших постах. В прошлом году мы даже записали на эту тему целый подкаст. Однако ввиду возрастающего количества разных сервисов и все чаще случающихся атак на пользовательские аккаунты (как, например, перехваты контроля над учетными записями iCloud) мы решили посвятить этому виду аутентификации отдельную статью и рассказать о том, что это такое, как она работает и почему ее стоит использовать везде, где это возможно.
Что такое двухфакторная аутентификация?
Двухфакторная аутентификация — это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. На практике это обычно выглядит так: первый рубеж — это логин и пароль, второй — специальный код, приходящий по SMS или электронной почте. Реже второй «слой» защиты запрашивает специальный USB-ключ или биометрические данные пользователя. В общем, суть подхода очень проста: чтобы куда-то попасть, нужно дважды подтвердить тот факт, что вы — это вы, причем при помощи двух «ключей», одним из которых вы владеете, а другой держите в памяти.
Впрочем, двухфакторная защита не панацея от угона аккаунта, но достаточно надежный барьер, серьезно усложняющий злоумышленникам доступ к чужим данным и в какой-то степени нивелирующий недостатки классической парольной защиты. Ведь у паролей, на которых основано подавляющее большинство авторизационных механизмов в Интернете, есть неизбежные недостатки, которые фактически являются продолжением достоинств: короткие и простые пароли легко запомнить, но так же легко подобрать, а длинные и сложные трудно взломать, но и запомнить непросто. По этой причине многие люди используют довольно тривиальные пароли, причем сразу во многих местах. Второй фактор в подобных случаях оказывается крайне полезен, поскольку, даже если пароль был скомпрометирован, злоумышленнику придется или раздобыть мобильник жертвы, или угнать ее почтовый ящик.
Несмотря на многочисленные попытки современного человечества заменить пароли чем-то поинтереснее, полностью избавиться от этой привычной всем парадигмы оказалось не так просто, так что двухфакторную аутентификацию можно считать одним из самых надежных механизмов защиты на сегодняшний день. Кстати, этот метод удобен еще и тем, что способен предупреждать хозяина аккаунта о попытке взлома: если на ваш телефон или почту вдруг приходит сообщение с одноразовым кодом при том, что вы никаких попыток логина не предпринимали, значит, вас пытаются взломать — самое время менять оказавшийся ненадежным пароль!
Где можно включить двухфакторную аутентификацию?
Ответом на этот вопрос может служить простое правило: если используемый вами сервис содержит важные для вас данные и позволяет включить двухфакторную аутентификацию, активируйте ее не раздумывая! Вот, скажем, какой-нибудь Pinterest. Ну, не знаю… Если бы у меня был аккаунт в этом сервисе, я бы вряд ли захотел каждый раз проходить долгую процедуру двухслойной авторизации. А вот интернет-банкинг, аккаунты в соцсетях, учетка в iCloud, почтовые ящики и особенно ваши служебные учетные записи — все это однозначно стоит защитить двухфакторной аутентификацией. Сервисы Google, Apple и все основные социальные сети позволяют это сделать в настройках без особого труда.
Двухфакторная аутентификация — один из лучших методов защиты ваших аккаунтов #security
К слову, если у вас есть свой сайт, скажем, на базе WordPress или другой подобной платформе, включить в настройках двухфакторную защиту тоже не будет лишним. В общем, повторюсь: если аккаунт и его содержимое вам дороги, не игнорируйте возможность усилить защиту.
Какие еще существуют виды двухфакторной аутентификации?
Выше я уже упомянул рассылку специального кода в виде SMS и email-сообщений и USB-ключи и смарт-карты, используемые преимущественно для доступа к некоторым видам интернет-ресурсов и VPN-сетям. Кроме того, существуют еще генераторы кодов (в виде брелока с кнопкой и небольшим экранчиком), технология SecureID и некоторые другие специфические методы, характерные в основном для корпоративного сектора. Есть и менее современные интерпретации: например, так называемые TAN-пароли (TAN, Transaction Authentication Number — аутентификационный номер транзакции). Возможно, вы даже сталкивались с ними, если были клиентом какого-нибудь не самого прогрессивного банка: при подключении интернет-банкинга клиенту выдавалась бумажка с заранее сформированным списком одноразовых паролей, которые вводятся один за другим при каждом входе в систему и/или совершении транзакции. Кстати, ваша банковская карта и PIN тоже формируют систему двухфакторной аутентификации: карточка — «ключ», которым вы владеете, а PIN-код к ней — «ключ», который вы запоминаете.
Как я уже упомянул выше, существует и биометрический способ идентификации пользователя, который часто выступает в роли вторичного фактора защиты: одни системы подразумевают сканирование отпечатка пальца, другие определяют человека по глазам, есть даже те, которые ориентируются по «рисунку» сердцебиения. Но пока это все довольно экзотические методы, хотя и куда более популярные, чем, скажем, электромагнитные татуировки, которые по примеру радиочипов могут служить вторичным фактором аутентификации пользователя. Я бы от такой не отказался 🙂
Делаем web-аутентификацию через блокчейн
Недавно я участвовал в Ethereum-хакатоне, и сегодня хочу рассказать о проекте EtherAuth, с которым команда MixBytes заняла третье место. EtherAuth — это попытка сделать децентрализованную версию входа на сайт при помощи внешней учетной записи. Как кнопка войти через Facebook, только без Facebook.
Проблема и пути решения
Если вы хотите сделать на своем сайте закрытую область для пользователей, вам приходится выбирать: разработать свою систему идентификации, аутентификации и авторизации пользователей, или воспользоваться готовым решением. Готовое решение означает, что у вашего пользователя уже есть учетная запись в какой-то системе (Facebook, Google, Yahoo, Outlook, или даже просто email). И вы используете соответствующий механизм (чаще всего протокол OAuth 2.0), чтобы убедиться, что некто пытающийся залогиниться на ваш сайт с использованием внешнего идентификатора пользователя и есть этот пользователь.
Последний вариант проще в реализации, но возникает риск для пользователя: если что-то случится с его основным аккаунтом (например, Facebook заблокирует аккаунт без объяснения причин), он потеряет также доступ и к своей информации на вашем сайте.
Кроме того, если я как пользователь хочу войти на какой-то сайт, которому я пока не доверяю, я сталкиваюсь с необходимостью предоставить этому сайту доступ к своей персональной информации, например email или возраст. Если сайт поддерживает только вход внешней учетной записью, я должен буквально сделать выбор: отказаться от использования сайта или пожертвовать своей анонимностью.
Большинство пользователей заканчивает тем, что жертвует анонимностью со словами «да что страшного может случиться, мне нечего скрывать». К несчастью, большинство атак, ориентированных на неподготовленного пользователя и заканчивающихся денежными потерями, начинаются с похожих слов. «Что страшного может случиться, если я перешлю сотруднику банка код из смс?». «Что страшного может случиться если я перешлю сотруднику техподдержки заголовки запроса?». Ответ на этот вопрос чаще всего узнают когда уже ничего нельзя сделать.
Как тут может помочь Ethereum? Мы уже поняли, что основных проблем три:
Мы можем использовать сеть Ethereum вместо внешней системы и хранить в ней только необходимый набор данных. Надо позаботиться о том, чтобы не хранить в публичном доступе секретную информацию, но поскольку любой кошелек в сети Ethereum фактически является парой криптографически стойких ключей, в которой публичный ключ определяет адрес кошелька, а приватный ключ никогда не передается по сети и известен только владельцу, мы можем использовать асимметричное шифрование для аутентификации пользователей.
В простейшем случае можно использовать адрес Ethereum-кошелька как идентификатор пользователя. Но здесь возникает проблема: в случае утечки ключа пользователь теряет доступ к системе навсегда. Точнее, с момента, когда секретный ключ пользователя стал известен злоумышленнику или просто случайно попал в публичный доступ, мы не можем использовать такой ключ для аутентификации.
Реализация
В нашем решении я написал простой смарт-контракт EtherAuth для хранения идентификаторов пользователей и связанных с ними адресов кошельков. Идентификатор пользователя — это просто строка UTF-8 размером от 2 до 32 байт. Ее придумывает один раз сам пользователь и позже использует для входа на любой сайт, поддерживающий EtherAuth. Сегодня я бы добавил еще ограничение на возможные символы, входящие в строку, оставив возможность использования символов латинского алфавита и арабских цифр (подмножества 7-битной кодировки ASCII), чтобы ограничить возможность создания внешне похожих логинов.
При создании аккаунта в EtherAuth задается пара ключей: авторизационный ключ (authAddr) и ключ для восстановления доступа (recoveryKey). Название recoveryKey не совсем удачное, поскольку этот адрес используется для управления учетной записью, а не только для восстановления. При создании оба адреса равны адресу кошелька, от имени которого отправлена транзакция. Но пользователю, который заботится о своей безопасности, стоит создать отдельный управляющий ключ и хранить его в месте, недоступном по сети. Я бы даже хранил его на бумаге в сейфе в виде 12 мнемонических слов, позволяющих при необходимости воссоздать пару ключей.
Также разумно использовать отдельный адрес кошелька для аутентификации, отделяя его от адреса кошелька, в котором хранится весь ваш Эфир. Связь authKey с адресом кошелька, создавшего учетную запись, все еще можно проследить, анализируя последовательность транзакций смарт-контракта. Сейчас нельзя задать отдельный authKey и recoveryKey при создании аккаунта. Однако, если доработать смарт-контракт в этом направлении, адрес, создавший аккаунт, не обязательно будет связан с владельцем аккаунта, что позволит все желающим защитить свою анонимность.
Для взаимодействия пользователя со смарт-контрактом мы создали отдельную веб-страницу. На ней можно создать аккаунт, поменять его ключи или удалить. Для работы пользователю потребуется установить браузерный плагин MetaMask. Если вы уже активно используете сеть Ethereum, скорее всего вы этот плагин уже установили, то есть основная масса пользователей, желающих войти на сайт через Ethereum, не столкнется с дополнительной преградой на своем пути.
Общий процесс аутентификации пользователя с использованием EtherAuth выглядит так:
В нашем решении для хакатона мы для простоты совместили backend- и frontend-части, получился один большой frontend. В реальной жизни важно, чтобы проверка аутентификации происходила в неподконтрольной пользователю среде, то есть не в браузере, а на сервере.
Из проблем, с которыми мы столкнулись, можно отметить проверку подписи во frontend-части. В браузере не оказалось поддержки эллиптических кривых, поэтому пришлось добавить в смарт-контракт функцию, которая возвращает результат ecrecover от сообщения и научиться правильно передавать в нее параметры (доставать их из подписанного MetaMask-ом сообщения).
В результате за два дня мы получили proof-of-concept децентрализованной аутентификации с использованием сети Ethereum и плагина MetaMask. Мы понимаем, как нужно доработать эту систему, чтобы добавить в нее анонимность для пользователя. Пользователь имеет возможность восстановить доступ в случае утечки его основного ключа (но не в случае утечки ключа восстановления). Децентрализованная система неподвластна цензуре крупных структур, таких как Google или Facebook. При необходимости цензуры сайт должен осуществлять ее самостоятельно, но он может сделать это только в рамках собственной системы, не влияя на доступ пользователя к другим системам. Сеть Ethereum не очень быстро проводит транзакции (при создании аккаунта пользователю может быть придется подождать несколько минут), но доставать данные и осуществлять проверку аутентификации пользователя можно очень быстро. Это решение хорошо масштабируется, поскольку узлов с данными очень много, и любой желающий может добавить еще один в любой момент. Трудоемкость же внедрения такого решения для владельцев сайтов не выше, чем трудоемкость внедрения поддержки OAuth 2.0.
Заключение
Безусловно, сегодня пользователей использующих сеть Ethereum ничтожно мало в сравнении с числом пользователей Facebook. Однако популярность блокчейн-технологий растет, и я верю, что в обозримом будущем таких пользователей будет становиться все больше и больше, а значит появится возможность для использования децентрализованной аутентификации в промышленных системах.