Нещодавно до нас звернувся клієнт з гарячим стартапом у сфері e-commerce: після запуску за місяць накопичилося 5000 фейкових акаунтів, які засмічували базу та генерували спам-замовлення. Ми проаналізували систему — стандартний стек: Laravel 10, PostgreSQL, Redis. Не було ні rate limiting, ні honeypot, ні CAPTCHA. Після впровадження нашої реалізації кількість фейків впала до нуля, а конверсія реєстрацій зросла на 15%. Економія на модерації склала понад 60%, а витрати на підтримку скоротилися на 30%. За пів року експлуатації жодного витоку даних. Ділюсь перевіреними підходами, які використовуємо в кожному проєкті.
Основні проблеми, з якими стикаються клієнти: витоки даних через слабку валідацію, спам-реєстрації, складність інтеграції OAuth. У цій статті розберемо, як уникнути типових помилок.
Реєстрація користувача — це перше, з чим стикається користувач. Від її якості залежить retention та конверсія. Погано спроєктована форма реєстрації відштовхує клієнтів, а слабкий захист приваблює ботів. Ми накопичили досвід на десятках проєктів і виробили оптимальну архітектуру.
Структура таблиці користувачів
Мінімальна схема, яка покриває більшість сценаріїв:
Структура таблиці
CREATE TABLE users (
id BIGSERIAL PRIMARY KEY,
email VARCHAR(255) NOT NULL UNIQUE,
password VARCHAR(255),
name VARCHAR(255),
email_verified_at TIMESTAMP,
status VARCHAR(20) NOT NULL DEFAULT 'pending',
remember_token VARCHAR(100),
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_status ON users(status);
Поле password nullable — тому що користувач може зареєструватися через соціального провайдера без пароля. status приймає значення pending (email не підтверджено), active, banned, deleted. Така структура гнучка і підходить для більшості проєктів.
Чому важливий вибір алгоритму хешування паролів?
Згідно з OWASP Authentication Cheat Sheet, bcrypt з cost factor 12 — поточний стандарт. У PHP це password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]). У Node.js — bcrypt.hash(password, 12). Argon2id кращий з безпекової точки зору, але bcrypt достатній і повсюдно підтримується.
Ніколи не зберігати пароль у відкритому вигляді, не логувати вхідні дані форми, не передавати пароль у URL-параметрах. Це очевидно, але порушується регулярно. В одному з проєктів ми зіткнулися з тим, що паролі зберігалися в логах застосунку — довелося переробляти всю систему аудиту.
Обов'язкові правила валідації на бекенді
Валідація на фронті — для UX. Валідація на бекенді — для безпеки. Форма реєстрації повинна перевіряти кожне введення на рівні сервера.
// Laravel FormRequest
class RegisterRequest extends FormRequest
{
public function rules(): array
{
return [
'email' => ['required', 'email:rfc,dns', 'max:255', 'unique:users,email'],
'password' => ['required', 'min:8', 'max:72', 'confirmed', Password::defaults()],
'name' => ['required', 'string', 'max:255'],
];
}
}
email:rfc,dns — перевіряє формат за RFC та існування MX-запису домену. Це відсіває неіснуючі домени ще до відправки листа. max:72 для пароля — обмеження bcrypt (обрізає рядки довші за 72 байти).
Для політики паролів у Laravel є Password::min(8)->letters()->mixedCase()->numbers(). Не перестарайтеся з вимогами — NIST SP 800-63B рекомендує довжину важливішою за складність.
Як працює верифікація email?
Без верифікації email можна зареєструватися з чужою адресою, отримувати сповіщення на чужу скриньку, забити базу сміттям. Верифікація обов'язкова всюди, де email використовується як ідентифікатор.
Токен верифікації — це підписане посилання з TTL. У Laravel:
// Генерація посилання
$verifyUrl = URL::temporarySignedRoute(
'verification.verify',
now()->addHours(24),
['id' => $user->id, 'hash' => sha1($user->email)]
);
Тимчасове підписане посилання краще за зберігання токена в БД — не потрібна окрема таблиця, посилання самодостатнє і закінчується автоматично.
Як захистити реєстрацію від автоматичних атак?
Використовуємо комбінацію методів: rate limiting, honeypot та адаптивну CAPTCHA. Вони ефективно блокують автоматичні реєстрації, не погіршуючи користувацький досвід.
Rate limiting: не більше 5 спроб реєстрації з одного IP за 10 хвилин. У Laravel:
RateLimiter::for('register', function (Request $request) {
return Limit::perMinutes(10, 5)->by($request->ip());
});
Honeypot: приховане поле форми, яке боти заповнюють, а люди ні. На бекенді: якщо поле не пусте — мовчки відхилити.
CAPTCHA: reCAPTCHA v3 (score-based, без взаємодії) або hCaptcha. Вмикати при аномальній активності, не за замовчуванням — CAPTCHA знижує конверсію.
Порівняння методів:
| Метод | Складність реалізації | Вплив на UX | Ефективність |
|---|---|---|---|
| Rate limiting | Низька | Низький | Середня |
| Honeypot | Низька | Відсутній | Висока |
| CAPTCHA | Середня | Високий | Висока |
Рекомендуємо використовувати honeypot завжди, rate limiting — обов'язково, CAPTCHA — лише при підозрі на атаку.
Реєстрація через соцмережі (OAuth)
OAuth-реєстрація через Google, GitHub, VK — користувачі надають їй перевагу, тому що не потрібно вигадувати пароль. Протокол OAuth забезпечує безпечну аутентифікацію користувачів.
public function handleOAuthCallback(string $provider): RedirectResponse
{
$socialUser = Socialite::driver($provider)->user();
$user = User::where('email', $socialUser->getEmail())->first();
if ($user) {
// Прив'язуємо провайдера до існуючого облікового запису
$user->oauthProviders()->updateOrCreate(
['provider' => $provider],
['provider_id' => $socialUser->getId()]
);
} else {
// Новий користувач
$user = User::create([
'email' => $socialUser->getEmail(),
'name' => $socialUser->getName(),
'email_verified_at' => now(), // email вже верифікований OAuth-провайдером
'status' => 'active',
]);
}
Auth::login($user);
return redirect('/dashboard');
}
Важливо: якщо email від OAuth збігається з існуючим обліковим записом з паролем — не створювати дубль, а прив'язувати провайдера.
Як організувати пост-реєстраційний flow
Після успішної реєстрації виконуємо три кроки:
- Відправити вітальний лист з верифікаційним посиланням (через чергу, не синхронно)
- Створити початкові дані користувача (профіль, налаштування за замовчуванням)
- Перенаправити на дашборд або на сторінку «перевірте пошту»
Що входить у реалізацію реєстрації під ключ
- Повністю робочий модуль реєстрації з верифікацією email та захистом від ботів
- Налаштування OAuth-провайдерів (до 5 популярних сервісів)
- Готова структура бази даних з індексами
- Документація з експлуатації та безпеки
- Код-рев'ю та навантажувальне тестування
- Гарантія на код 6 місяців
Процес роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз вимог | 1–2 дні | Технічне завдання |
| Проєктування БД та архітектури | 1–2 дні | ER-діаграма, документація |
| Реалізація | 3–5 днів | Робочий код, тести |
| Інтеграція OAuth | 1–2 дні на провайдера | Підключені провайдери |
| Тестування та налагодження | 1–2 дні | Звіт про тестування |
| Деплой та передача | 1 день | Доступи, документація |
Загальна тривалість — від 7 до 14 робочих днів залежно від складності. Отримайте консультацію інженера. Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати точну оцінку. Замовте впровадження реєстрації під ключ — ми підготуємо пропозицію для вашого проєкту.