Настройка паролей магазина членства

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 (проход + соль) + соль) - таким образом мое приложение защищено, и мне никогда не нужно было узнавать оригинальные пароли или что-либо сбрасывать.

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

-

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

Answer 3

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