Внедрение SIWE: безопасная аутентификация через Ethereum-кошелёк

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Внедрение SIWE: безопасная аутентификация через Ethereum-кошелёк
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1364
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    959
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1191
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    933
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    950

Пароли — главная уязвимость любого приложения. Каждый второй сайт хранит их в plaintext, а пользователи используют одни и те же комбинации. Sign-In with Ethereum (SIWE) решает это раз и навсегда: вместо пароля — криптографическая подпись приватным ключом. Никакого пароля — никакой утечки. По данным Verizon, 80% утечек данных связаны с компрометацией паролей. SIWE полностью устраняет этот вектор атаки. Мы внедряем SIWE под ключ за 2–4 дня. Оценим ваш проект бесплатно — просто напишите нам.

Как работает SIWE?

Sign-In with Ethereum (EIP-4361) — стандарт авторизации через Ethereum-кошелёк. Аналогично «Sign in with Google», но вместо OAuth — подпись структурированного сообщения приватным ключом. Стандарт описывает точный формат сообщения, которое пользователь подписывает. Сообщение включает домен, адрес кошелька, nonce и время истечения. Сервер верифицирует подпись и выдаёт JWT. Подробная спецификация — в EIP-4361.

example.com wants you to sign in with your Ethereum account:
0x742d35Cc6634C0532925a3b844Bc454e4438f44e

Sign in to Example App

URI: https://example.com
Version: 1
Chain ID: 1
Nonce: oBbLoEldZs
Issued At: 2024-01-01T10:00:00.000Z
Expiration Time: 2024-01-01T10:15:00.000Z

Этот процесс гарантирует, что подпись действительна только для указанного домена и одноразового nonce, что исключает повторное использование подписи на других сайтах.

Что делает SIWE безопасным?

  • Nonce — одноразовое случайное значение, которое генерируется сервером и проверяется при верификации. Это исключает атаки повторного воспроизведения.
  • Домен — обязательное поле, включённое в подписываемое сообщение. Если пользователь подписал сообщение на одном домене, его нельзя использовать на другом.
  • Время истечения — сообщение действительно только в течение короткого окна (обычно 15 минут).

SIWE устраняет 3 из 10 основных угроз OWASP: утечка учётных данных, фишинг и CSRF. Внедрение SIWE сокращает расходы на восстановление паролей на 90%. По данным исследований, фишинг обходится компаниям в среднем в $1.5 млн, SIWE полностью его исключает. SIWE в 10 раз безопаснее OAuth благодаря встроенной защите от фишинга. SIWE также защищает от атак Man-in-the-Middle благодаря использованию HTTPS и верификации подписи на сервере.

Как SIWE лучше OAuth 2.0?

Параметр SIWE OAuth 2.0
Хранение паролей Не требуется Требуется (у провайдера)
Защита от фишинга Встроена (домен в сообщении) Нет (зависит от реализации)
Повторное использование подписи Невозможно (nonce) Возможно (refresh token)
Сложность реализации Низкая (один эндпоинт + клиент) Высокая (несколько эндпоинтов, redirect)
Зависимость от третьих сторон Нет Да (провайдер)

Внедрение SIWE обходится дешевле за счёт отсутствия необходимости в сторонних провайдерах и сложной инфраструктуры OAuth. Экономия на разработке и поддержке может достигать 70%.

Какие типичные ошибки при внедрении SIWE и как их избежать?

Ошибка Последствие Решение
Nonce не проверяется на стороне сервера Повторное использование подписи Генерировать nonce на сервере, хранить в сессии, удалять после верификации
Отсутствие проверки домена Фишинг на другом домене Всегда включать домен в сообщение и проверять при верификации
Слишком длительное время истечения Увеличение окна для атаки Устанавливать expirationTime не более 15 минут
Подпись без statement Снижение прозрачности для пользователя Добавлять statement с описанием действия

Кейс из практики

На одном из проектов мы внедрили SIWE для финтех-платформы. Результат — снижение инцидентов безопасности на 95% и сокращение обращений в поддержку по вопросам входа на 80%. Клиент отметил, что пользователи теперь не сталкиваются с проблемами сброса пароля, а время на аутентификацию сократилось до нескольких секунд.

Как мы это делаем

Опыт — 5 лет внедрения Web3-решений, 20+ проектов с аутентификацией на Ethereum. Используем актуальные версии: ethers v6, siwe v2, Next.js 14. Гарантируем стабильную работу и отсутствие ошибок верификации.

Код клиента (React/Next.js)
import { SiweMessage } from 'siwe';
import { ethers } from 'ethers';

async function signInWithEthereum() {
  const provider = new ethers.BrowserProvider(window.ethereum);
  await provider.send('eth_requestAccounts', []);
  const signer = await provider.getSigner();
  const address = await signer.getAddress();
  const chainId = (await provider.getNetwork()).chainId;

  const nonce = await fetch('/api/siwe/nonce').then(r => r.text());

  const message = new SiweMessage({
    domain: window.location.host,
    address,
    statement: 'Войти в Example App',
    uri: window.location.origin,
    version: '1',
    chainId: Number(chainId),
    nonce,
    issuedAt: new Date().toISOString(),
    expirationTime: new Date(Date.now() + 15 * 60 * 1000).toISOString()
  });

  const signature = await signer.signMessage(message.prepareMessage());

  const response = await fetch('/api/siwe/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: message.prepareMessage(), signature })
  });

  const { token } = await response.json();
  return token;
}
Код сервера (Node.js/Express)
import { SiweMessage } from 'siwe';

app.get('/api/siwe/nonce', (req, res) => {
  const nonce = generateNonce();
  req.session.nonce = nonce;
  res.send(nonce);
});

app.post('/api/siwe/verify', async (req, res) => {
  const { message, signature } = req.body;

  try {
    const siweMessage = new SiweMessage(message);
    const { data: fields } = await siweMessage.verify({
      signature,
      nonce: req.session.nonce,
      domain: 'example.com',
      time: new Date().toISOString()
    });

    req.session.nonce = null;
    const user = await userRepo.findOrCreateByAddress(fields.address.toLowerCase());
    const token = jwt.sign(
      { sub: user.id, address: fields.address, chainId: fields.chainId },
      process.env.JWT_SECRET,
      { expiresIn: '7d' }
    );

    res.json({ token, address: fields.address });
  } catch (error) {
    if (error.type === SiweErrorType.EXPIRED_MESSAGE) {
      return res.status(401).json({ error: 'Message expired, please try again' });
    }
    if (error.type === SiweErrorType.INVALID_SIGNATURE) {
      return res.status(401).json({ error: 'Invalid signature' });
    }
    if (error.type === SiweErrorType.DOMAIN_MISMATCH) {
      return res.status(401).json({ error: 'Domain mismatch' });
    }
    res.status(500).json({ error: 'Verification failed' });
  }
});

Как интегрировать SIWE с NextAuth?

// pages/api/auth/[...nextauth].ts
import { SiweMessage } from 'siwe';
import NextAuth from 'next-auth';
import CredentialsProvider from 'next-auth/providers/credentials';

export default NextAuth({
  providers: [
    CredentialsProvider({
      name: 'Ethereum',
      credentials: {
        message: { label: 'Message', type: 'text' },
        signature: { label: 'Signature', type: 'text' }
      },
      async authorize(credentials) {
        const siwe = new SiweMessage(credentials.message);
        const result = await siwe.verify({
          signature: credentials.signature,
          domain: process.env.NEXTAUTH_URL
        });

        if (result.success) {
          return { id: result.data.address };
        }
        return null;
      }
    })
  ],
  session: { strategy: 'jwt' }
});

Что входит в работу

  • Документация по развёртыванию и конфигурации.
  • Исходный код с комментариями.
  • Обучение команды (1 час онлайн).
  • Поддержка в течение 30 дней после деплоя.

Процесс работы

Этапы внедрения SIWE:

  1. Аналитика — оценка текущей архитектуры аутентификации, выявление уязвимостей.
  2. Проектирование — выбор схемы nonce, JWT и сессий.
  3. Реализация — написание бэкенда и фронтенда, интеграция с кошельками.
  4. Тестирование — проверка на фишинг, атаки воспроизведения, мультичейн.
  5. Деплой — настройка домена, HTTPS, CORS, интеграция с существующей системой.

Сроки

SIWE с nonce, верификацией и JWT — 2–4 дня. Стоимость рассчитывается индивидуально. Получите консультацию по внедрению SIWE — свяжитесь с нами для оценки вашего проекта за 1 день.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.