העברת משתמשים ללא אובדן סיסמאות – הגירה עצלה ו-ETL

העברת משתמשים – אתגר טכני שאנו פותרים ללא אובדן גישה

שירות העברת המשתמשים שלנו מתמחה בהעברת סיסמאות באמצעות טכניקות lazy migration ו-ETL, תוך הבטחה שלא יאבדו סיסמאות. כאשר עסק מחליט לעבור ל-CMS או framework חדש, הנושא הרגיש ביותר הוא המשתמשים. הסיסמאות שלהם מוצפנות עם האלגוריתם הישן—sha512 עם salt (Drupal 7), phpass (WordPress), או md5($password.$salt) מ-CRM מותאם אישית. המערכת החדשה לא מבינה את ה-hashes האלה, והעתקה פשוטה של מסד הנתונים לא תעבוד—אף אחד לא יוכל להתחבר. גרוע מכך, מהנדסים עושים לעתים קרובות את הטעות של העתקת טבלת המשתמשים כפי שהיא, רק כדי לגלות שכל הסיסמאות אינן תקפות. התוצאה היא איפוס סשנים המוני ואובדן נאמנות. ביצענו למעלה מ-50 העברות, כולל פרויקטים עם 200,000 משתמשים, ואנחנו יודעים כיצד להעביר משתמשים כך שהם אפילו לא ישימו לב למעבר. להלן אסטרטגיה מוכחת והכלים (Python, Golang, Laravel, Django) שבהם אנו משתמשים בכל פרויקט. השירותים שלנו מתחילים ב-$2,000 עבור מסדי נתונים עד 100,000 משתמשים, עם חיסכון אופייני של 30-50% בהשוואה לבנייה מחדש מלאה של מערכות. עבור פרויקט טיפוסי עם 100k משתמשים, העלות היא $2,000 והחיסכון הממוצע הוא $3,000-$5,000. אנו מבטיחים שאף משתמש לא יאבד גישה.

בעיות שאנו פותרים

• חוסר התאמה של אלגוריתם ה-hashing: המערכת הישנה משתמשת ב-sha512 או MD5, והחדשה רק ב-bcrypt.
• משתמשים כפולים לפי אימייל בעת מיזוג מסדי נתונים.
• אובדן תפקידים והרשאות גישה במהלך ההעברה.
• צורך לשמר סשנים פעילים ולהימנע מהתחברות חוזרת המונית.
• אינטגרציית SSO לדו-קיום זמני של פלטפורמות ישנות וחדשות.

למה Lazy Migration עדיפה על Rehashing מלא

Lazy migration מאפשרת העברת משתמשים ללא downtime או אובדן גישה. ה-hashes הישנים נשארים במסד הנתונים, ובכל התחברות נבדק האלגוריתם; עם הצלחה, הסיסמה עוברת rehash עם החדש. זה מהיר פי 3–5 מאיפוס מלא כפוי ואינו גורם לנטישת משתמשים. יתרה מכך, היא מאפשרת העברה הדרגתית ללא downtime—ניתן להעביר את מסד הנתונים ברקע בעוד 100% מהעומס נשאר על המערכת הישנה. 90% מהמשתמשים אפילו לא שמים לב לתהליך ההעברה. Lazy migration משמרת את תכונות ה-salting ו-key stretching הטבועות באלגוריתמים כמו bcrypt ו-PBKDF2, ומונעת התקפות rainbow table באמצעות ניצול גורם העלות האדפטיבי של bcrypt.

איפוס כפוי עבור אלגוריתמים ישנים

אם תמיכה באלגוריתמים מיושנים (MD5, SHA1) אינה רצויה, אנו שולחים למשתמשים אימייל עם token לאיפוס. זה בטוח יותר מאחסון hashes חלשים. תרחיש: סקריפט מוצא את כל המשתמשים עם אלגוריתם legacy_md5, מייצר token חד-פעמי, ושולח אימייל. תוקף ה-token הוא 7 ימים. לאחר שינוי מוצלח, הסיסמה נשמרת עם bcrypt.

כאשר המערכת החדשה אינה תומכת באלגוריתם הישן

במקרה זה, אנו מיישמים שכבת אימות ביניים. לדוגמה, עבור phpass (WordPress) אנו משתמשים ביישום Python מותאם אישית. "PHPass is a portable public domain password hashing framework"—האלגוריתם שלו נתמך באמצעות פונקציה מותאמת אישית. באופן דומה עבור PBKDF2 (Django) ו-sha512 (Drupal 7). זה שומר על תאימות ללא צורך בשכתוב המערכת כולה.

כיצד ליישם Lazy Migration

תוכנית שלב-אחר-שלב:

1. ניתוח ה-hashes הקיימים וזיהוי האלגוריתמים.
2. יישום פונקציית אימות לכל אלגוריתם.
3. הוספת לוגיקת rehashing בעת התחברות מוצלחת.
4. פיתוח סקריפט ETL להעברת נתונים.
5. בדיקה על עותק של מסד הנתונים.
6. הרצת ההעברה וניטור שגיאות.

הרעיון המרכזי הוא לאחסן את ה-hash המקורי ותווית האלגוריתם בשדה 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}")

טיפול בהתחברות ו-Rehashing

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

מה כלול בעבודת העברת המשתמשים

• ביקורת על מסד המשתמשים הנוכחי ואלגוריתמי ה-hashing.
• פיתוח סקריפטים של ETL עם מיפוי תפקידים ושדות נוספים.
• יישום lazy migration (או איפוס כפוי) עם בדיקה על עותק.
• הגדרת ניטור לאחר הפריסה (תצפית של 24 שעות).
• תיעוד נוהל rollback וגיבוי.

לוחות זמנים וטעויות נפוצות

לוחות זמנים משוערים

• למסדי נתונים עד 100,000 משתמשים: 2–3 ימי עבודה לביקורת, פיתוח ובדיקה.
• למסדי נתונים מ-100,000 עד 500,000 משתמשים: 5–7 ימים כולל ETL ובדיקות עומס.
• פרויקטים גדולים עם עשרות תפקידים ושדות מותאמים אישית עשויים לדרוש זמן נוסף.

טעויות נפוצות בהעברה

• חוסר בדיקות לכפילויות אימייל—מוביל לקונפליקטים ואובדן נתונים.
• התעלמות ממיפוי תפקידים—משתמשים מועברים אך מאבדים הרשאות גישה.
• ניסיון לבצע rehash לכל הסיסמאות בבת אחת—גורם לעומס CPU ושגיאות.
• חוסר תוכנית rollback—אין שחזור מהיר במקרה של כשל.
• אי סגירת סשנים ישנים—משתמשים נשארים במערכת עם נתונים ישנים.

טיפים:

• תמיד לבדוק על עותק של מסד הנתונים.
• להשתמש בטרנזקציות ובסקריפטים עם rollback.
• להגדיר ניטור שגיאות לאחר הפריסה (24 השעות הראשונות קריטיות).
• לשמור גיבוי של מסד הנתונים הישן וסקריפט העברה הפוכה.

השוואת אלגוריתמי Hashing

הזמינו ביקורת על הפרויקט שלכם—נתחיל ביום הראשון. צרו קשר לייעוץ וקבלו הערכה מדויקת עם תוצאה מובטחת.