Я группа одного человека, и мне нужно исправить проблему, из-за которой кто-то создал журнал. У меня есть клиентский сайт с паролями, которые хранятся небезопасно (обычный текст). Я хочу исправить это, но я просто хотел опубликовать этот процесс, чтобы убедиться, что я на правильном пути с переходом на хешированный пароль (скорее всего, md5).Проверка логики при небезопасных изменениях пароля
Вот мои шаги, которые я могу поверить, что смогу решить эту проблему.
- Измените таблицу, чтобы разрешить большой зашифрованный пароль.
- Добавить соль, предыдущий пароль и дату последнего смены пароля на таблицу.
- Сбросить все пароли, сохранив все старые пароли. Не уверен, использовать ли обычный текст или md5 при хранении старых паролей.
Заставить пользователей сменить пароль. В этом процессе я все еще не принимаю присяжных.
Я бы предположил, что разрешаю им входить в систему, проверяя пользователя, проверяя, имеет ли пароль 32 символа или меньше.
Если меньше, проверьте прошлый пароль для соответствия.
Если прошлый пароль соответствует, отправьте электронное письмо с временным токеном на страницу, чтобы сменить пароль.
ли этот звук разумные процессы? Часть меня беспокоит, когда они вынуждены менять свой пароль. Другой вариант - просто отправить им токен, чтобы изменить свой пароль при попытке войти в систему.
Заранее благодарен!
Если у вас есть пароли открытого текста пользователя, почему бы не просто MD5 их? в этом случае вам не нужно проверять определенную длину, и у вас есть некоторое мгновенное повышение безопасности. проверьте соль, если она определена или нет, если нет, то она преобразуется md5. когда пользователь передает свой новый пакет паролей с некоторой случайной солью, храните новый md5 и храните случайную соль, чтобы вы знали, что это преобразованный хеш. – atom
Я забыл упомянуть, что у меня есть причина полагать, что некоторые пароли могут быть скомпрометированы. –