Хэш пароля. Не шифруйте - это сложно и / или небезопасно. Не существует мыслимых обстоятельств, при которых было бы неправильно сбросить пароль на основе какого-либо другого проверяемого критерия в обычном бизнес-приложении или на веб-сайте. Я не уверен из вопроса, знакомы ли вы с принципом хеширования пароля, поэтому я объясню с основ ...
Когда пользователь первоначально выбирает свой пароль, вы запускаете однонаправленный алгоритм хеширования для текста. Это создает сигнатуру - вывод, который всегда будет производиться, если вы введете одну и ту же строку в алгоритм хеширования. Ключ в том, что вы не можете вернуться к паролю из хэша (следовательно, одностороннего). Затем вы сохраняете хеш, а не пароль. Когда пользователь возвращается, он должен снова ввести свой пароль, вы хэшируете его, используя тот же алгоритм, и сравниваете полученное значение с тем, что находится в БД - если они совпадают, вы знаете, что пользователь снова ввел ту же строку, но вы все равно не не знаю, или нужно знать, что это такое. Это гораздо более безопасно, чем решения, основанные на шифровании, где вы всегда можете восстановить открытый текст, если знаете ключ, который по определению должен быть известен серверу для проверки правильности ввода пароля.
Простой способ хэширования строки в .NET заключается в использовании System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(), который, несмотря на его длинное имя, является простой функцией, предназначенной для тех, кто использует проверку подлинности на основе форм ASP.NET, но такой же полезной в других местах. Вы можете указать MD5 или SHA1 в качестве своего алгоритма хеширования (или даже других алгоритмов хеширования, если они будут поддерживаться будущими версиями платформы). Я рекомендую SHA1, поскольку известно, что у MD5 есть слабые стороны, но, вероятно, и у SHA1 тоже есть.
Однако - в этой схеме есть недостаток. Если несколько пользователей выберут один и тот же пароль, они будут иметь одинаковый хэш. Если хакер получает доступ к вашим данным, он может выполнить атаку методом «грубой силы», хэшируя общие строки и сравнивая их с вашими сохраненными данными. Если они получили удар, они взломали все учетные записи, используя этот пароль. Поскольку пользователи, как правило, выбирают паршивые пароли и ненавидят делать безопасные пароли, которые они не могут запомнить, это делает систему, основанную на простых хешах паролей, немного хрупкой.
Что вы должны сделать, это соль хеш. Это просто означает добавление или добавление исходных данных - пароля - к произвольной строке символов. Эта соль должна быть как можно более случайной и иметь длину не менее нескольких символов (я рекомендую минимум 5) и предпочтительно произвольной длины. Вы сохраняете соль (необъясненную) в столбце в БД вместе с хешированной комбинацией соль + пароль. Когда пользователь возвращает, вы добавляете или добавляете соль к его вводу таким же образом, а затем выполняете сравнение хешей, как и раньше.
Это снижает эффективность атаки методом грубой силы, потому что у каждого пользователя должен быть свой хэш, даже если у него один и тот же пароль. Вы можете безопасно хранить соль в БД, потому что вычисление строки из ее хеша так же сложно, когда вы знаете некоторую строку, и то, когда вы ничего не знаете, при условии, что сам пароль длиннее соли и достаточно длинный. и достаточно сильные, чтобы тратить их в течение длительного времени грубой силой (по крайней мере, 6 символов, по крайней мере, с одним изменением регистра и числом или не буквенно-цифровым, я бы сказал).
Если кто-то имеет неограниченный доступ к вашим данным в течение неограниченного времени, он в конечном итоге взломает хешированные пароли. Но в итоге могут пройти месяцы или годы. И при условии, что вы знаете, что скомпрометированы, вы можете изменить пароль каждого перед тем, как это станет проблемой.