Проверка логики при небезопасных сменах паролей - PullRequest
0 голосов
/ 31 января 2012

Я группа из одного человека, и мне нужно решить проблему, которую кто-то создал журнал назад.У меня есть клиентский сайт, на котором пароли хранятся небезопасно (простой текст).Я хочу исправить это, но я просто хотел опубликовать процесс, чтобы убедиться, что я нахожусь на правильном пути с преобразованием в хешированный пароль (md5, скорее всего).

Вот мои шаги, в которые я могу поверить, что смогу решить эту проблему.

  1. Измените таблицу, чтобы увеличить зашифрованный пароль большего размера.
  2. Добавьте соль, предыдущий пароль и дату последнего изменения пароля в таблицу.
  3. Сброс всех паролей, сохранение всехстарые пароли.Не уверен, использовать ли обычный текст или md5 при хранении старых паролей.
  4. Заставить пользователей сменить пароль.Этот процесс я все еще хочу обсудить.

    • Я думаю, я позволю им войти в систему, проверяя пользователя, проверяя, является ли пароль 32 символами или менее.

    • Еслименьше, проверьте прошедший пароль на совпадение.

    • Если прошлый пароль совпадает, отправьте электронное письмо с временным токеном на страницу для изменения пароля.

Это звучит разумно, процессы?Меня беспокоит то, что они вынуждены сменить пароль.Другой вариант - просто отправить им маркер, чтобы он сменил пароль при попытке войти в систему.

Заранее спасибо!

1 Ответ

0 голосов
/ 31 января 2012

Я думаю, что вы должны разделить две проблемы:
1. шифрование паролей с использованием одностороннего шифрования
2. заставление клиентов менять свой пароль каждые 180 дней или около того

О #2: вполне допустимо просить пользователей менять свои пароли каждый период времени, но вы не должны делать его короче 180 дней, так как это становится очень раздражающим ...

...