Криптокошельки с мультифакторной аутентификацией: сравнительный тест защиты активов
Звучит как единый класс защиты, но на уровне архитектуры это разные слои, которые закрывают разные сценарии атаки.
Поэтому честный сравнительный тест криптокошельков с мультифакторной аутентификацией начинается с оговорки: сопоставимого независимого испытания, которое проверяло бы все эти решения по одной методике, в доступных данных нет. Зато можно сравнить их логику, понять, какой ключ они защищают и где остаётся поверхность для эксплойта. Для выбора это полезнее, чем выдавать разным технологиям условные баллы безопасности.
Что именно защищает второй фактор
У кастодиального аккаунта и self-custody-кошелька разные границы доверия. В первом случае пользователь входит в сервис, а тот управляет доступом к аккаунту и связанными с ним функциями. Во втором контроль над активами завязан на секретную фразу и приватные ключи пользователя. Дополнительная проверка входа в сервис сама по себе не становится вторым подтверждением каждой on-chain-транзакции.
Из-за этого термин «MFA» в Web3 стоит читать внимательно. Под ним могут скрываться:
- проверка входа в аккаунт с помощью TOTP, passkey, ключа безопасности, push-уведомления или SMS;
- физическое подтверждение подписи на отдельном аппаратном устройстве;
- выполнение транзакции после того, как её подтвердило заданное число владельцев смарт-аккаунта.
Все три подхода добавляют проверку, но на разных этапах. TOTP усложняет захват аккаунта через один пароль. Аппаратное устройство добавляет физический шаг для подписи. Мультисиг распределяет право на выполнение операции между несколькими владельцами. Это не взаимозаменяемые варианты и не ступени единой шкалы «от слабого к сильному».
Второй фактор имеет смысл только в контексте конкретного действия: входа, подписи или исполнения транзакции.
При выборе полезно сначала определить модель угроз. Если опасение — что злоумышленник получит пароль от аккаунта, нужны средства защиты входа и восстановления доступа. Если риск — вредоносная подпись в dApp, важны содержание транзакции, поведение кошелька и то, что пользователь подтверждает на устройстве. Если активами управляет команда, задача уже в том, чтобы один скомпрометированный ключ не мог единолично провести операцию.
Coinbase: защита входа и ловушка SMS
В справке Coinbase для доступа к аккаунту указана двухэтапная проверка. Среди доступных методов перечислены ключ безопасности, passkey, приложение-аутентификатор с TOTP, push-уведомление и SMS. Сам сервис называет SMS наименее защищённым вариантом и рекомендует добавить резервные методы.
TOTP генерирует код на основе текущего времени и секретного ключа. Такой код не привязан к доставке сообщения оператором связи, поэтому сценарий переноса номера, известный как SIM-swap или porting attack, не перехватывает его так же, как SMS. Но TOTP не превращает аккаунт в неуязвимый: он защищает вход в рамках своей модели, а не гарантирует безопасность устройства пользователя, seed-фразы или каждой операции в блокчейне.
SMS удобен именно тем, что код приходит на привычный телефон. Но привязка к номеру создаёт отдельный риск: если атакующий добьётся переноса номера на другую SIM-карту или перехвата контроля над ним, он может получить сообщения с кодами. Coinbase указывает, что её SMS-код состоит из шести цифр. Само число здесь не меняет ключевой вывод: слабое место связано не с длиной кода, а с каналом доставки и контролем над номером.
| Механизм | Что подтверждает | Основное ограничение |
|---|---|---|
| SMS | Вход в аккаунт через код на телефон | Зависит от безопасности номера; возможен риск SIM-swap |
| TOTP | Вход с одноразовым кодом из приложения | Не подтверждает автоматически каждую on-chain-транзакцию |
| Passkey или ключ безопасности | Дополнительную проверку доступа к аккаунту | Доступность и поведение зависят от конкретного сервиса и конфигурации |
| Аппаратный кошелёк | Подпись операции на физическом устройстве | Не блокирует вредоносную подпись, если пользователь её подтверждает |
| Safe с порогом владельцев | Исполнение операции после нужного числа подтверждений | Требует продуманной конфигурации владельцев и порога |
Для аккаунта разумно не оставлять SMS единственным резервным способом, если сервис предлагает другие методы. При этом доступные варианты могут различаться в зависимости от страны, приложения и версии сервиса, поэтому таблица описывает типы механизмов, а не универсальную комплектацию каждого кошелька.
Есть и важная граница по названию продукта. Coinbase Wallet описан как self-custody-кошелёк: recovery phrase даёт доступ к кошельку, а Coinbase не может восстановить утраченную фразу или переместить активы вместо пользователя. В приложении Base предусмотрен App Lock, который можно настроить на биометрическую разблокировку или код-пароль при открытии приложения и/или проведении транзакции. Это локальная блокировка приложения, а не то же самое, что MFA для входа в кастодиальный аккаунт.
У Coinbase также есть доверенные контакты для восстановления аккаунта: можно добавить от двух до пяти таких контактов. Этот механизм предназначен для восстановления доступа, а не для обычного подтверждения каждой операции. Смешивать recovery-флоу с защитой транзакций — удобный способ получить ложное чувство безопасности.
Аппаратное подтверждение: физический шаг не равен иммунитету к эксплойту
Аппаратный кошелёк хранит ключевой материал отдельно от обычной среды работы и требует физически подтвердить транзакцию на устройстве. В описании MetaMask аппаратное устройство выступает отдельным средством защиты секретной фразы восстановления и приватных ключей; для транзакции пользователь должен подтвердить действие физически.
В этой схеме появляется дополнительная граница: запрос из браузера или dApp сам по себе не должен завершаться подписью без участия устройства. Но физическое нажатие не означает, что транзакция безопасна по смыслу. Пользователь может подтвердить вредоносный вызов смарт-контракта, а устройство не гарантирует защиту от раскрытия seed-фразы. Производитель Ledger отдельно предупреждает об обоих ограничениях: аппаратный кошелёк не спасает, если секретная фраза стала известна атакующему, и не блокирует подписание вредоносных смарт-контрактов.
Для DeFi это особенно заметно на взаимодействиях с контрактами. Кошелёк может показать запрос на подпись, но безопасность зависит от того, что именно пользователь разрешает: разовую операцию, разрешение на токены или иной вызов контракта. Если подтверждать всё подряд, аппаратный ключ становится качественно защищённым инструментом для выполнения плохого решения. Устройство изолирует ключ, но не заменяет анализ транзакции.
Практически сравнение безопасности аппаратных и программных кошельков упирается в компромисс. Программный кошелёк быстрее подключается к dApps и удобнее для частых операций. Аппаратный добавляет отдельное физическое подтверждение и лучше отделяет ключ от повседневной среды. Но ни один из этих форм-факторов сам по себе не решает проблему фишинга, ошибочного разрешения или компрометации recovery phrase.
Для активов, которыми часто взаимодействуют с DeFi, полезно разделять роли кошельков: один использовать для регулярных действий с ограниченным объёмом средств, другой — для хранения, где транзакции редкие и требуют более внимательной проверки. Это не магический стандарт и не обещание защиты от всех атак, а способ уменьшить последствия ошибки в горячем операционном контуре.
Safe: MFA как правило исполнения смарт-аккаунта
В Safe подтверждение встроено в логику смарт-аккаунта. Владелец задаёт список участников и порог: транзакция исполняется после того, как её подтвердит необходимое число владельцев. В роли владельцев могут выступать обычные внешние аккаунты (EOA), другие смарт-аккаунты или passkey.
Порог можно установить от одного владельца до общего числа владельцев аккаунта. Список владельцев и само значение порога можно менять. В этом и сила, и ответственность архитектуры: безопасность зависит не от абстрактного наличия слова «мультисиг», а от конфигурации ключей и процедур управления ими.
Для примера, аккаунт с несколькими владельцами и порогом, требующим нескольких подтверждений, затрудняет единоличный вывод средств при компрометации одного ключа. Но если порог равен одному, наличие нескольких владельцев не означает, что каждой операции нужно несколько подписей. И наоборот, высокий порог способен усложнить легитимное управление, если часть владельцев потеряет доступ или окажется недоступна в момент срочной операции.
Перед настройкой Safe стоит пройтись по конкретным вопросам:
1. Кто владеет ключами. Если все ключи находятся на устройствах одного человека или в одном облачном аккаунте, распределение по адресам может оказаться формальным.
2. Какой порог нужен для обычной операции. Он должен ограничивать последствия компрометации, но оставаться выполнимым при реальном составе участников.
3. Кто и как меняет владельцев. Изменение списка владельцев и порога само становится критической операцией управления.
4. Что происходит при потере доступа. Восстановление ключа, замена владельца и экстренные действия должны быть продуманы заранее, а не во время инцидента.
5. Какие аккаунты используются как владельцы. Safe допускает разные типы владельцев, и их собственные модели безопасности тоже входят в общую поверхность риска.
Мультисиг уместен для казначейств DAO, командных кошельков и хранилищ, где единоличное распоряжение активами нежелательно. Для личного кошелька с небольшим числом операций он может добавить лишнюю операционную сложность. Здесь нет универсального «правильного порога»: решение определяется числом участников, ценой задержки и последствиями компрометации.
Мультисиг распределяет право на исполнение, но не отменяет необходимость защищать каждый ключ и саму процедуру управления владельцами.
Где ломается защита: фишинг, recovery phrase и слепая подпись
У систем MFA есть общий предел: они проверяют конкретное условие, но не оценивают весь контекст действия. TOTP может подтвердить вход, не защищая приватный ключ self-custody-кошелька. Аппаратное устройство может изолировать ключ, но подтвердить операцию, смысл которой пользователь не понял. Safe может требовать несколько подписей, но не устранит риск, если владельцы согласованно одобрят вредоносную транзакцию или управление аккаунтом настроено небрежно.
Уязвимости чаще возникают на стыках механизмов:
- Подмена сценария входа. Пользователь вводит пароль и код на фишинговой странице, принимая её за интерфейс сервиса.
- SIM-swap. Контроль над номером телефона позволяет атакующему перехватывать SMS-коды, если SMS используется для доступа.
- Утечка recovery phrase. Кто получил фразу восстановления self-custody-кошелька, тот может получить контроль над активами; App Lock и MFA другого аккаунта её не заменяют.
- Вредоносное разрешение. Пользователь подтверждает действие контракта, которое открывает нежелательный доступ к токенам или выполняет другую опасную операцию.
- Слепая подпись. Запрос подтверждается без достаточного понимания его содержимого; аппаратное устройство не гарантирует, что пользователь распознал последствия.
- Слабая конфигурация Safe. Несколько владельцев присутствуют в списке, но порог, распределение ключей или процедура их замены не соответствуют реальной модели риска.
Из этого складывается не рейтинг «самый безопасный кошелёк», а карта задач. Для защиты входа в аккаунт подходят методы аутентификации, которые предлагает конкретный сервис; SMS среди них Coinbase оценивает как наименее защищённый. Для физического контроля подписи подходят аппаратные устройства, если пользователь проверяет и понимает операцию. Для совместного управления активами подходит смарт-аккаунт с порогом подтверждений, который соответствует команде и процессу.
Как выбрать защиту под свой контур
Сравнение криптокошельков с MFA имеет смысл только после ответа на вопрос, что именно требуется защитить. Если речь об аккаунте сервиса, изучайте методы входа и восстановления. Если речь о self-custody, следите за сохранностью seed-фразы и моделью подтверждения транзакций. Если активами распоряжается несколько человек, оценивайте порог Safe и независимость ключей владельцев.
Ни один из описанных механизмов не даёт основания объявить один кошелёк абсолютным победителем: сопоставимых независимых испытаний с единой методикой нет, а модели угроз различаются. Практичный выбор строится слоями. Уберите SMS как единственную опору, если есть альтернативы; отделите ключ от повседневной среды там, где это оправдано; проверяйте содержание подписей; для общего казначейства задайте понятные правила владельцев и порога.
В Web3 защита работает не как один переключатель MFA, а как цепочка: доступ, хранение ключа, подтверждение и исполнение. Слабое звено обычно находится не в названии кошелька, а в том, какое действие пользователь готов подтвердить и кто ещё способен его совершить.
