Аутентификация в веб-приложении: как сделать правильно

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

Первое правило: не изобретайте хеширование

Пароли хранятся только в виде хеша, созданного алгоритмом, специально предназначенным для паролей: bcrypt, scrypt или argon2. Быстрые хеш-функции вроде SHA-256 для этого не годятся именно потому, что они быстрые — перебор на видеокарте идёт миллиардами вариантов в секунду.

import { createHash } from "node:crypto"
import { hash, verify } from "@node-rs/argon2"

// Неверно: быстрая хеш-функция, подбирается перебором
const bad = createHash("sha256").update(password).digest("hex")

// Верно: алгоритм с настраиваемой стоимостью вычисления
const passwordHash = await hash(password, {
  memoryCost: 19456,
  timeCost: 2,
  parallelism: 1,
})

// Проверка при входе
const isValid = await verify(passwordHash, submittedPassword)

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

Спор о сессиях и JWT сводится к одному вопросу: можно ли мгновенно отозвать доступ. Идентификатор сессии в базе отзывается удалением строки. Подписанный токен действует до истечения срока, и отозвать его без дополнительного хранилища нельзя.

Для веб-приложения с личным кабинетом мы почти всегда выбираем сессии в базе: одно чтение по индексу дешевле, чем невозможность выкинуть скомпрометированную сессию.

Настройка cookie

Сессионная cookie требует четырёх атрибутов. Пропуск любого из них открывает конкретный вектор атаки, поэтому запомнить стоит все.

cookies().set("session", sessionId, {
  // Недоступна из JavaScript: защита при межсайтовом скриптинге
  httpOnly: true,
  // Только по HTTPS
  secure: process.env.NODE_ENV === "production",
  // Не отправляется при межсайтовых переходах: защита от CSRF
  sameSite: "lax",
  // Ограничивает область действия
  path: "/",
  // Конечный срок жизни: сессия не живёт вечно
  maxAge: 60 * 60 * 24 * 7,
})

Защита от перебора

Без ограничения частоты попыток форма входа перебирается автоматически. Ограничивать нужно по двум ключам одновременно: по адресу и по логину. Первый останавливает перебор с одной машины, второй — распределённый перебор одной учётной записи.

const ipKey = `login:ip:${ip}`
const userKey = `login:user:${email.toLowerCase()}`

const [ipAttempts, userAttempts] = await Promise.all([
  redis.incr(ipKey),
  redis.incr(userKey),
])

// Окно ставим только при первой попытке, чтобы счётчик не продлевался
if (ipAttempts === 1) await redis.expire(ipKey, 900)
if (userAttempts === 1) await redis.expire(userKey, 900)

if (ipAttempts > 20 || userAttempts > 5) {
  return { error: "Слишком много попыток входа. Повторите через 15 минут." }
}

Четыре ошибки, которые встречаются чаще всего

• Разные сообщения для неверного логина и неверного пароля. Так проверяется существование учётной записи. Сообщение должно быть одно.
• Сессия не обновляется после входа. Позволяет закрепить заранее известный идентификатор сессии за жертвой.
• Запрос данных без проверки владельца. Проверка прав в интерфейсе не защищает: ограничение должно быть в самом запросе к базе.
• Бессрочные ссылки восстановления пароля. Срок жизни — не более часа, и ссылка становится недействительной после первого использования.

Аутентификация — та часть системы, где самостоятельное творчество почти всегда проигрывает проверенной библиотеке.