Как работает безопасная функция «потерянного пароля»?

Question

«Сделан» способ сделать сброс пароля, кажется следующее:

1. Создает временный маркер (zs8Abn27)
2. знака Хранить в базе данных вместе с истечением срока
3. Email токена пользователь
4. пользователь переходит на /password_reset?t=zs8Abn27
5. Токен проверяется по базе данных на валидность
6. Если действительный пользователь получает новый пароль, который хранится в базе данных (соленая и bcrypted, конечно)

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

Для записи это полностью концептуально, мне просто интересно, как вы можете сделать такую ​​функцию безопасной.

Answer 1

Ну, во-первых, не только из-за этого вопроса, мы должны убедиться, что хакер не нарушает работу базы данных и получает доступ для чтения/записи.

Другим подходом было бы хранение токенов не в базе данных, а в файловой системе. В папке, которая не читается, но только пользователем веб-сервера, защищена от доступа .htaccess, регулярно очищается cron, поэтому токены истекают относительно быстро. Таким образом, код, ответственный за восстановление пароля, будет проверять этот файл, а не базу данных.

Но опять же, это тоже можно взломать.

Answer 2

Ваше описание нужного процесса верное.

Если хакер получает доступ к вашей базе данных, все находится в режиме ожидания. Ваши усилия должны быть направлены на обеспечение того, что это невозможно.

Answer 3

В дополнение к тому, что было сказано, вы могли бы использовать маркер, прежде чем хранить его в своей БД, но после отправки его пользователю.

Answer 4

Считать Everything you ever wanted to know about building a secure password reset feature.

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

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