Создать временный URL для сброса пароля

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

PasswordResetToken UNIQUEIDENTIFIER,
PasswordResetExpiration DATETIME

Если вы используете маршрут дополнительной таблицы,вы можете также добавить столбец UserID, сделать его первичным ключом и ссылкой на ключ foriegn обратно в таблицу users. Было бы также рекомендовано установить уникальное ограничение. Тогда ты ... просто используйте Guid в вашем asp.net применение в качестве маркера.

Поток может быть примерно таким:

1. пользователь запрашивает сброс пароля для своей учетной записи
2. вы вставляете новую запись в таблицу (или обновляете свою пользовательскую запись), устанавливая PasswordResetExpiration на дату в будущем (DateTime.Сейчас.AddDays(1)), и установите токен в Guid.NewGuid ()
3. отправьте пользователю ссылку на свой ResetPassword.страница aspx с идентификатором guid в строке запроса (http://www.yoursite.com/ResetPassword.aspx?token=Guid-here )
4. используйте ResetPassword.страница aspx для проверки полей маркера и срока действия. (То есть убедитесь, что дата-время.Теперь
5. укажите простую форму, которая позволяет пользователю сбросить этот пароль.

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

@Alex

Вы также можете использовать System.Безопасность.Классы криптографии в .NET для хэш-алгоритмов. Например:

using System.Security.Cryptography;
...
var hash = SHA256CryptoServiceProvider.Create().ComputeHash(myTokenToHash);
...

Здесь система.Guid класс в вашем друге, так как он будет генерировать уникальное (ну, достаточно уникальное) 128-битное число:

• Создайте новый Guid (System.идентификатор GUID.NewGuid ())
• храните этот Guid где-нибудь (возможно, объект приложения?)
• отправьте пользовательский URL-адрес по электронной почте с этим идентификатором Guid
• Когда пользователь заходит на сайт, заставьте его ввести пароль, который вы отправили по электронной почте
• Если пароли совпадают, продолжайте и заставьте их ввести новый пароль

Я использовал класс хэширования для создания уникальных автоматических Логинов, состоящих из текущей даты/времени и адреса электронной почты пользователя:

string strNow = DateTime.Now.ToString();
string strHash = strNow + strEmail;
strHash = Hash.GetHash(strHash, Hash.HashType.SHA1);

Получить хэш-класс из: http://www.developerfusion.com/code/4601/create-hashes-md5-sha1-sha256-sha384-sha512/

Тогда просто возьмите его из URL, используя:

if (Request.QueryString["hash"] != null)
{
                //extract Hash from the URL
                string strHash = Request.QueryString["hash"];
}

Я бы обязательно включил базу данных в этот процесс. После запроса на сброс рекомендуется указать, что учетная запись заблокирована.

Например, если вы меняете свой pw, потому что считаете, что ваша учетная запись может быть скомпрометирована, вы определенно не хотите, чтобы она оставалась доступной, пока вы идете на процесс изменения.

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

Это дает вам две вещи:

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

Целью отправки некоторых данных / строк на электронную почту пользователя является проверка владельца учетной записи. Пожалуйста, обратите внимание на некоторые моменты:

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

Результат: Я думаю, будет лучше, если ты

1. объедините электронную почту пользователя со Строковой ссылкой, а затем зашифруйте их (не хэш, потому что хэшированное значение не может быть обратным) и отправить пользователю электронная почта.
2. пользователь нажимает, и ваша страница получает зашифрованное значение.
3. расшифровать значение.
4. Извлечение электронной почты пользователя.
5. найти электронную почту в базе данных.
6. сравнить строку из полученной ссылки с другой прикреплен к пользователю электронная почта в базе данных.

Удачи.

Я бы использовал хэш-код для проверки сведений в url-адресе сброса пароля. Все это можно сделать, ничего не записывая в БД и не посылая никакой привилегированной информации аттакеру.

Чтобы кратко объяснить обычную соль пароля и хэширование; скажем, соль-это 1111, а пароль-это password, вы объединяете их и хэшируете строку 1111password, скажем, это дает вам хэш 9999, затем вы сохраняете исходную соль 1111 и хэш 9999 в вашей записи пользователя.

Когда вы проверяете a пароль вы используете сохраненную соль, объединяете попытку пароля, хэшируете ее и сравниваете с сохраненным хэшем. Например, asecret становится 1111asecret, но хэшируется в 8888. Это не соответствует исходному хэшу, поэтому совпадение пароля не удается.

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

Для URL сброса пароля я бы ввел уникальный идентификатор пользователя, то есть адрес электронной почты, дату запрос сделан, и новый хэш. Этот хэш будет сгенерирован из тех деталей, которые объединены вместе, плюс соль и хэш, уже сохраненные для пользователя.

Например:

Email: user@example.com
Request Date: 2014-07-17
Salt: 1111
Hash: 9999

Генерирует новый хэш из тех, которые сцеплены, т. е. 'user@example.com2014-07-1711119999', скажем, это дает хэш 7777.

URL-адрес, который я затем генерирую, будет иметь адрес электронной почты, дату запроса и новый хэш:

https:\\www.example.com\ResetPassword?email=user@example.com&requestdate=2014-07-17&hash=7777

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

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

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