Реализация переноса пользователей и паролей при миграции сайта

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

Отметим: когда бизнес решает переехать на новую CMS или фреймворк, самый деликатный вопрос — пользователи. Их пароли зашифрованы старым алгоритмом — sha512 с солью (Drupal 7), phpass (WordPress) или md5($password.$salt) из самописной CRM. Новая система эти хэши не понимает, и просто скопировать базу нельзя — никто не войдёт. Более того, инженеры часто допускают ошибку: копируют таблицу пользователей как есть, а потом выясняют, что все пароли недействительны. Результат — массовый сброс сессий и потеря лояльности. Мы провели более 50 миграций, включая проекты с 200 000 пользователей, и знаем, как провести перенос так, чтобы пользователи даже не заметили переезда. Ниже — проверенная стратегия и инструменты (Python, Golang, Laravel, Django), которые мы используем в каждом проекте. Мы гарантируем, что ни один пользователь не потеряет доступ.

Какие проблемы решаем?

• Несовместимость алгоритмов хэширования: старая система использует sha512 или MD5, новая — только bcrypt.
• Дубликаты пользователей по email при объединении баз.
• Потеря ролей и прав доступа при переносе.
• Необходимость сохранить активные сессии и избежать массового перелогина.
• SSO-интеграция для временной совместной работы старой и новой платформ.

Почему lazy migration лучше полного рехэширования?

Lazy migration позволяет перенести пользователей без простоя и потери доступа. Старые хэши остаются в базе, а при каждом входе проверяется алгоритм и при успехе пароль перехэшируется новым. Это в 3–5 раз быстрее полного принудительного сброса и не вызывает отток аудитории. Кроме того, он позволяет постепенно переносить пользователей без простоя — можно мигрировать базу в фоне, а 100% нагрузка на старую систему сохраняется.

Принудительный сброс для legacy алгоритмов

Если поддержка устаревших алгоритмов (MD5, SHA1) нежелательна, мы отправляем пользователям email с токеном для сброса. Это безопаснее, чем хранить ненадёжные хэши. Сценарий: скрипт находит всех пользователей с алгоритмом legacy_md5, генерирует одноразовый токен и отправляет письмо. Срок действия токена — 7 дней. После успешной смены пароль сохраняется уже с bcrypt.

Что делать, если алгоритм не поддерживается новой системой?

В этом случае мы внедряем промежуточный слой верификации. Например, для phpass (WordPress) используем собственную реализацию на Python. «PHPass is a portable public domain password hashing framework» — его алгоритм поддерживается через кастомную функцию. Аналогично для PBKDF2 (Django) и sha512 (Drupal 7). Это позволяет сохранить совместимость без переписывания всей системы.

Как реализовать lazy migration?

Пошаговый план:

1. Проанализируйте существующие хэши и определите алгоритмы.
2. Реализуйте функцию верификации для каждого алгоритма.
3. Добавьте логику перехэширования при успешном входе.
4. Разработайте ETL-скрипт для переноса данных.
5. Протестируйте на копии базы.
6. Запустите миграцию и мониторьте ошибки.

Основная идея — хранить исходный хэш и метку алгоритма в поле password_algorithm. При входе вызываем функцию verify_password, которая проверяет алгоритм, и при успехе — upgrade_password_hash. Рассмотрим реализацию на Python.

# models/user.py class User(BaseModel): password_hash: str password_algorithm: str # 'bcrypt', 'phpass', 'sha512', 'legacy_md5' def verify_password(self, plain_password: str) -> bool: if self.password_algorithm == 'bcrypt': return bcrypt.checkpw(plain_password.encode(), self.password_hash.encode()) elif self.password_algorithm == 'phpass': return phpass_check(plain_password, self.password_hash) elif self.password_algorithm == 'legacy_md5': return hashlib.md5(plain_password.encode()).hexdigest() == self.password_hash elif self.password_algorithm == 'pbkdf2_sha256': return django_pbkdf2_check(plain_password, self.password_hash) return False def upgrade_password_hash(self, plain_password: str): new_hash = bcrypt.hashpw(plain_password.encode(), bcrypt.gensalt(rounds=12)) self.password_hash = new_hash.decode() self.password_algorithm = 'bcrypt' db.save(self) 

Проверка совместимости phpass (WordPress)

import hashlib ITOA64 = './0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' def phpass_check(password: str, stored_hash: str) -> bool: if stored_hash.startswith('$P$') or stored_hash.startswith('$H$'): return _phpass_verify(password, stored_hash) return hashlib.md5(password.encode()).hexdigest() == stored_hash def _phpass_verify(password: str, hash_str: str) -> bool: count_log2 = ITOA64.index(hash_str[3]) count = 1 << count_log2 salt = hash_str[4:12] hash_val = hashlib.md5((salt + password).encode()).digest() for _ in range(count): hash_val = hashlib.md5(hash_val + password.encode()).digest() output = _encode64(hash_val, 16) return hash_str[12:34] == output[:22] 

ETL: перенос пользователей с маппингом ролей

Для массового переноса используем ETL-скрипт. Пример для WordPress:

def migrate_users_from_wordpress(wp_db, new_db): cursor = wp_db.cursor(dictionary=True) cursor.execute(""" SELECT u.ID, u.user_login, u.user_pass, u.user_email, u.user_registered, u.display_name, um.meta_value as first_name, um2.meta_value as last_name FROM wp_users u LEFT JOIN wp_usermeta um ON u.ID = um.user_id AND um.meta_key = 'first_name' LEFT JOIN wp_usermeta um2 ON u.ID = um2.user_id AND um2.meta_key = 'last_name' ORDER BY u.ID """) migrated = 0 skipped = 0 for wp_user in cursor.fetchall(): existing = new_db.get_user_by_email(wp_user['user_email']) if existing: skipped += 1 continue algorithm = detect_wp_hash_algorithm(wp_user['user_pass']) new_db.create_user({ 'username': wp_user['user_login'], 'email': wp_user['user_email'], 'password_hash': wp_user['user_pass'], 'password_algorithm': algorithm, 'display_name': wp_user['display_name'], 'created_at': wp_user['user_registered'], 'legacy_id': wp_user['ID'], }) # Маппинг ролей: из wp_usermeta meta_key = 'wp_capabilities' roles = get_user_roles(wp_db, wp_user['ID']) new_db.assign_roles(wp_user['user_email'], roles) migrated += 1 print(f"Migrated: {migrated}, Skipped: {skipped}") 

Обработка входа и перехэширование

def login(email: str, password: str): user = db.get_user_by_email(email) if not user: return None if user.verify_password(password): if user.password_algorithm != 'bcrypt': user.upgrade_password_hash(password) return create_session(user) return None 

Что входит в работу по миграции пользователей?

• Аудит текущей базы пользователей и алгоритмов хэширования.
• Разработка скриптов ETL с учётом маппинга ролей и дополнительных полей.
• Реализация lazy migration (или принудительного сброса) с тестированием на копии.
• Настройка мониторинга ошибок после деплоя (24-часовое наблюдение).
• Документация по процедуре отката и резервное копирование.

Сроки выполнения и типичные ошибки

Ориентировочные сроки

• Для базы до 100 000 пользователей: 2–3 рабочих дня на аудит, разработку и тестирование.
• Для базы от 100 000 до 500 000: 5–7 дней с учётом ETL и нагрузочного тестирования.
• В крупных проектах с десятками ролей и кастомными полями срок может быть увеличен.

Типичные ошибки при миграции

• Пропуск проверки дубликатов по email — приводит к конфликтам и потере данных.
• Игнорирование маппинга ролей — пользователь переносится, но теряет права доступа.
• Попытка рехэшировать все пароли сразу — вызывает CPU-нагрузку и ошибки.
• Отсутствие плана отката — при неудаче нет быстрого восстановления.
• Незакрытие старых сессий — пользователи остаются в системе под старыми данными.

Советы:

• Всегда тестируйте на копии базы.
• Используйте транзакции и скрипты с rollback.
• Настройте мониторинг ошибок после деплоя (первые 24 часа критичны).
• Храните резервную копию старой базы и скрипт обратной миграции.

Сравнение алгоритмов хэширования

Закажите аудит вашего проекта — первый день бесплатно. Свяжитесь с нами для консультации и получите точную смету с гарантией результата.