Безопасность сброса пароля в приложении ASP.NET - PullRequest
3 голосов
/ 01 февраля 2011

У меня есть ASP.NET, который позволяет пользователям сбрасывать пароли.

Процесс

  1. Пользователь нажимает ссылку сброса по электронной почте.Ссылка содержит маркер безопасности.
  2. Пользователь попадает на страницу 1 приложения и отвечает на вопросы безопасности
  3. Если вопросы правильные, перейдите на страницу 2 и сбросьте пароли.

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

Чтобы защититься от этого, я планирую.

  1. Всегда проверяйте, ссылающаяся страница - это страница 1, когда на странице 2, и отскок, если ее нет
  2. . Поставьте маркер безопасности, который приходит в электронном письме.ссылка в сеансе на странице 1 и разрешить использовать страницу 2 только в том случае, если она все еще находится в сеансе.
  3. Низкое время ожидания сеанса, поэтому ограниченное время для ввода пароля.Могли бы также записать в базу данных время, когда они завершили страницу 1.

У меня вопрос такой. Это хитрый план или кто-то может увидеть в нем изъян?

Ответы [ 3 ]

2 голосов
/ 01 февраля 2011

Почему бы вам не оставить пользователя на той же странице? Я бы использовал WizardControl .

Если вы решите придерживаться двухстраничного подхода, вы можете установить флаг в своей базе данных, когда на вопросы безопасности для данного токена были даны правильные ответы. На странице 2 вы проверяете, установлен ли флаг, если нет -> перенаправить на страницу 1.

2 голосов
/ 01 февраля 2011

Шаг 1 вашего плана, вероятно, будет работать не очень хорошо, полагаться на доступные значения реферера не рекомендуется, поскольку его а) легко подделать, б) часто отключают параноидальные пользователи.

Шаг 2Похоже, вы хотите реализовать подход типа токена CSRF, это хорошая идея.

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

2 голосов
/ 01 февраля 2011

Я думал, что токен должен быть сохранен в базе данных и признан недействительным, если:

  • истекает определенный промежуток времени
  • генерируется новое электронное письмо
  • пользователь сбрасываетпароль
...