Методы, позволяющие избежать атаки оракула на соответствующие учетные записи, информация о том, что система сброса пароля может привести к

Question

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

Рассмотрим эти противоречивые требования:

• Взломщик A вводит в форму системы потенциальных имен пользователей (или электронных писем) в попытке обнаружить совпадения в настоящее время в системе.

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

• Пользователь B пытается сбросить свой пароль, но ошибочные или, что еще хуже, ошибочно вводит имя пользователя, так что оно не соответствует ни одной учетной записи в файле. Таким образом, их запрос на сброс никогда не будет выполнен.

В идеале, их ошибка должна быть понятна им через несколько секунд после того, как они запросят сброс, с дружеским сообщением типа «Извините, у нас нет такого имени пользователя (или адреса электронной почты) в файле. Вы можете попробовать проверить орфографию, или создать новую учетную запись. " В противном случае, они могут проверить свою электронную почту, ничего не найти, подождать, ничего, сбросить снова, ничего (потому что совпадение не доступно для отправки), возможно, заняться своими делами в другом месте? Если вам повезет, позвоните в отдел обслуживания клиентов?

Какие существуют способы разрешения этих противоречивых целей?

Edit:

Обдумав проблему, я полагаю, что одним из способов ее решения может быть использование только адреса электронной почты, и, если это письмо не существует в системе, отправить a "Эта учетная запись не существует, вот ссылка для создания новой учетной записи "на электронную почту вместо ссылки сброса.

Таким образом, пользователь всегда будет получать информацию, а взломщик сможет получать только электронные письма, отправленные на те учетные записи, к которым у него уже есть доступ, что для них бесполезно.

Имеет смысл? Проблемы с этим подходом?

Answer 1

Удобство использования для пользователя B, вероятно, превосходит риск безопасности для Cracker A, поэтому ключ, вероятно, заключается в том, чтобы ограничить то, что Cracker A может узнать.

Одним из способов обработки Cracker A является ограничение скорости ответов. Пользователь B будет отправлять один запрос каждые 10 секунд (скажем) из-за быстрого (неправильного) ввода своего имени и будет делать это с того же IP-адреса. Взломщик А будет пытаться отправить как можно больше запросов в максимально короткие сроки, возможно, из ботнета многих зараженных компьютеров под его командованием. Если вы всегда тратите (по крайней мере) 5 секунд на ответ на запрос, даже если ваша система прекрасно справляется с управлением запросами быстрее, то Cracker A может выполнять поиск только в ограниченной части пространства имен за разумное время. На самом деле реализовать это может быть сложнее, чем мне хотелось бы думать.

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