Настройка членства в хранилище Пароли

Question

Я переношу приложение из ColdFusion в ASP.Net MVC и имею небольшую проблему, я не могу показаться своей головой. Исходное приложение хранит пароли пользователей в хэш-формате MD5 без соли в базе данных. Я использую членский магазин ASP.Net и хотел бы разрешить как бесшовный переход для существующих пользователей, насколько это возможно. Вот о возможностях, о которых я думал ...

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

2) Пользователи регистрируются по электронной почте, а не по имени на экране, поэтому я подумывал об изменении пароля каждого пользователя на свое имя экрана и принуждении их изменить его после первого входа. Единственная проблема заключается в том, что я не уверен, что могу обновить свой пароль через SQL без текущего пароля. Выполнение процесса aspnet_Membership_SetPassword не означает, что он шифрует пароль самостоятельно.

Что вы говорите?

Answer 1

Я использовал вариант # 1 в прямом приложении. Он отлично работал, пользователи так и не заметили изменения, насколько мне известно.

Несколько уточнений:

• Вам не нужно подсказывать им обновить свой пароль; они предоставили вам открытый текст, чтобы войти в систему (и вы знаете, что это правильный текст, поскольку он хэшируется правильно), поэтому просто перейдите и установите это как свой пароль.
• Убедитесь, что вы очистили устаревший пароль, если они используют функцию сброса пароля.

Я бы ни при каких обстоятельствах не использовал вариант 2; это дико небезопасно.

Еще одна вещь - можно установить пароль, не зная его текущего, просто требуется два шага.

1. Сбросить пароль пользователя. Теперь вы знаете пароль сброса.
2. Используйте новый пароль восстановления, чтобы установить пароль на известное значение.

Answer 2

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

Например мой первоначальный хеш был MD5 (передача + соль)

Я модернизировал все до SHA256 (MD5 (передача + соль) + соль) - таким образом мое приложение является безопасным, и я никогда не нуждался, чтобы узнать оригинальные пароли или сбросить что-либо.

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

-

Bah- Извиняюсь, это на самом деле не с учетом членства ASP.net, как я использую пользовательский класс аутентификации в моем приложении. Я по-прежнему считаю, что это один из наиболее эффективных методов для обновления, но я не уверен в специфике членства ASP.net.

Answer 3

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