SIWE: «Войти через Ethereum» — безопасно или ловушка

SIWE: «Войти через Ethereum» — безопасно или ловушка? 🔐🪪

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

<b>Что такое SIWE простыми словами</b>

Это подпись сообщения формата EIP‑4361 для входа на сайт без пароля. Важное: SIWE — не платёж и не разрешение на списание. Если в «подписать» подмешаны поля про разрешения/трату — это уже не чистый SIWE.

<b>Из чего состоит корректная подпись</b>

— <b>domain</b> = домен сайта, где вы находитесь;

— <b>address</b> = ваш адрес;

— <b>statement</b> = понятная цель (например, «вход на example.com»);

— <b>uri</b>, <b>version</b>, <b>chainId</b>;

— <b>nonce</b> (одноразовый код) и <b>issuedAt</b>/<b>expirationTime</b>.

Нет слов «approve/permit/operator/spender» — иначе это уже про доступ к средствам.

<b>Красные флаги в подписи</b>

— domain не совпадает с открытым сайтом;

— пустой или мутный statement;

— бессрочная подпись без expiration;

— в полях мелькают «Approval/Permit/SetApprovalForAll» или адрес «оператора».

<b>Мини‑чек‑лист перед кликом «Подписать»</b>

— читаемые поля EIP‑4361, без blind‑signing;

— домен и chainId совпадают с вашим окном;

— есть nonce и срок действия;

— никаких «spender/operator/permit»;

— аппаратный ключ и блокировка опасных разрешений;

— для сделок — <b>только эскроу</b>: платёж проверяется по TXID/логам, а не «подписью входа».

<b>Как эскроу решает проблему</b>

Мы фиксируем условия в одном чате с код‑фразой, подписываем реквизиты через <b>EIP‑712</b> (сеть, адрес, сумма, срок), покупатель вносит депозит — средства «на паузе». Поставка выполнена — гарант сверяет <b>TXID и логи</b> (Transfer/Deposit/Release) и делает релиз. Для крупных сумм — мультисиг 2‑из‑3, timelock 24–72 часа, holdback 5–10%.

<b>Пример безопасного сценария</b>

1) Вход на маркетплейс по чистому SIWE (только авторизация).

2) Условия сделки фиксируются у гаранта, реквизиты — через EIP‑712.

3) Депозит у эскроу → передача актива → проверка логов → релиз.

4) Любые «ApprovalForAll/Permit» под видом оплаты — отказ.

<b>Типовые ошибки</b>

— путать «вход» с «оплатой»;

— доверять «скрину перевода» вместо TXID;

— слепо подписывать в мобильном кошельке;

— менять реквизиты после депозита.

Полезные материалы

• EIP‑4361 (Sign‑In with Ethereum): https://eips.ethereum.org/EIPS/eip-4361 — структура безопасного сообщения для входа.

• SIWE (Login.xyz) — гайд и примеры: https://login.xyz — как правильно формировать и проверять подпись.

• WalletConnect — проверка сообщений и безопасность: https://docs.walletconnect.com — лучшие практики валидации подписи.

Наши ресурсы

• Сайт сервиса: https://guarantor.su

• Telegram‑бот: @GARANT_S_bot

Итог: <b>SIWE — только про вход, деньги — через эскроу</b>. Хотите разбор вашей подписи/процесса? Пишите — настроим чек‑лист и сопроводим сделку.

Как вы проверяете SIWE перед подписью: смотрите domain/nonce или используете отдельный тестовый кошелёк? Делитесь опытом и задавайте вопросы в комментариях.