Как будет работать функция защищенного "утерянного пароля"?
"Готовый" способ сброса пароля выглядит следующим образом:
- Создать временный токен (
zs8Abn27) - Хранить токен в базе данных вместе со сроком действия
- Почтовый токен пользователю
- Пользователь переходит к
/password_reset?t=zs8Abn27 - Токен проверяется на соответствие с базой данных
- Если действительный пользователь получает новый пароль, который хранится в вашей базе данных (конечно, соленый и зашифрованный)
Мой вопрос: если хакер получит доступ на чтение / запись к вашей базе данных, он не сможет просто создать свои собственные токены и получить доступ таким образом? Даже если у них только есть доступ для чтения, они могут использовать токены, которые могут видеть, чтобы получить временный доступ.
Для протокола это полностью концептуально, мне просто любопытно, как сделать такую функцию безопасной.
4 ответа
Ну, во-первых, и не только из-за этого, нам нужно убедиться, что хакер не взломает базу данных и не получит доступ на чтение / запись.
Другой подход - хранить токены не в базе данных, а в файловой системе. В папке, которая не читается, но только пользователем веб-сервера, защищена от доступа .htaccessрегулярно очищается cronТаким образом, токены истекают относительно быстро. Таким образом, код, отвечающий за восстановление пароля, будет проверять этот файл, а не базу данных.
Но опять же, это тоже можно взломать.
Прочитайте все, что вы когда-либо хотели знать о создании функции безопасного сброса пароля.
Да, тот, кто имеет доступ к базе данных, может создавать свои собственные токены, но в любом случае он может просто сбросить пароли на те, которые им нравятся (при условии, что они знают используемый алгоритм хеширования). Кроме того, они всегда могут создавать новые учетные записи, повышать привилегии или выполнять любое количество других вредоносных задач.
Предположим, что если база данных взломана, у вас возникнут проблемы такого масштаба, которые делают доступ к токенам сброса незначительным!
Ваше описание требуемого процесса является правильным.
Если хакер получает доступ к вашей базе данных, все скрыто. Ваши усилия должны быть направлены на то, чтобы это было невозможно.
Кроме того, что было сказано, вы можете хешировать токен перед тем, как сохранить его в своей БД, но после отправки его пользователю по почте.