Покращення хешу паролів

[AIlkiv]

У старій толоці паролі хешувалися password_hash(md5()) і зберігалися в bb_users.user_password2 Новий рушій хешує md5(md5()) і зберігає в bb_users.user_password

Треба зроби, щоб новий рушій torrentpier хешував і перевіряв по password_hash(md5())

[chief-j]

Зроблю

[chief-j]

Наскільки я зрозумів, на толоці паролі хешовані у md5(), потім md5() захешований у password_hash()?

[AIlkiv]

Так

[chief-j]

54

[yukoff]

@konfuciusu У #76 стовпець user_password2 так і залишився - я так розумію, що достатньо

ALTER TABLE users DROP COLUMN user_password, CHANGE user_password2 user_password ...

за умови, що цей тікет також вирішиться?

[konfuciusu]

@yukoff так

[yukoff]

Для сумісності з міграцією старої схеми пропоную робити так:

• створити тимчасову таблицю, скажімо tmp_migrate_users ( id int not null, password varchar(60) not null) -- бо тільки на першому кроці ми будемо знати, чи ми на тестовій, чи це вже міграція старої;
• записати туди наявних на тестовій інсталяції користувачів;
• для адміна записати новий пароль (тобто, той самий, але вже через password_hash());
• для наявних в тестовій інсталяції користувачів поставити test;
• після процесу міграції будемо вже мати bb_users.user_password varchar(60) замість varchar(32) в типовій тестової конфігурації -- чи то перейменований з user_password2, чи конвертований в процесі міграції -- тож оновлюємо паролі для користувачів, що ми їх записали на другому кроці
• дропаємо таблицю tmp_migrate_users з першого кроку

[konfuciusu]

@yukoff мені здається, ви не так зрозуміли. В страій базі вже використовується password_hash(), це issue стосується TP2.

toloka.to: password_hash(md5()) TP2: md5(md5())

План: змінити md5(md5()) на password_hash(md5()), тобто не треба зміни паролів.

[yukoff]

@konfuciusu Та гадаю все ж я все правильно зрозумів, бо саме про TP2 мова і йде ;)

Коли міграція запускатиметься вперше (незалежно від того, чи це база старого рушія, чи вже TP2), ще невідомо, на якій саме версії бази це відбувається (немає таблиці migrations із застосованими міграціями, т.зв. нульова версія). Щодо конкретно паролів, то ось як це буде відбуватись:

• якщо ми бачимо, що ми на версії бази старого рушія, то вважаємо (як і було сказано), що паролі вже password_hash(md5()) і зберігаються у стовпці user_password2 - ми його просто перейменовуємо назад у user_password (це відбувається у міграції 20170601000000);
• якщо ж ми бачимо, що присутні таблиці нового рушія, отже відповідно ми на версії бази нового рушія (TP2) і паролі тут (для типових користувачів, які типово присутні після встановлення TP2) md5(md5()), отже ми створюємо тимчасову таблицю, записуємо туди ІД та нові паролі для тестових користувачів, і наприкінці процесу міграції оновлюємо вже bb_users та дропаємо тимчасову таблицю.

Власне, весь процес створювався, аби виключити необхідність робити на 900-тисячній таблиці щось типу

SELECT user_id FROM bb_users WHERE LENGTH(user_password) = 32;

(поганенький приклад, але він гарно демонструє суть).