Пароли для приложений, использующих стороннюю аутентификацию?

Question

У меня есть приложение ASP.NET MVC, в которое я только что интегрировал стороннюю систему федеративной идентификации RPX . Интеграция работает нормально, но у меня возникли некоторые трудности, связанные с тем, что с ней делать на уровне ASP.NET.

Поскольку идентификаторы обрабатываются извне, мне не нужны пароли в моем приложении: я никогда не получаю пароль пользователя, только его личность. Однако для работы провайдера членства в ASP.NET требуется, чтобы пароли передавались для создания пользователя, входа в него и т. Д.

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

Мне было бы интересно услышать, как другие сайты решают эту проблему, например, StackOverflow.

[См. Также мой другой вопрос , касающийся поставщиков членства для такого приложения.]

Answer 1

но я обеспокоен тем, что это сделает данные моего пользователя незащищенными.

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

Тогда пароль, хранящийся на вашей стороне, становится нематериальным, потому что это не секрет - если я смогу определить, какой пароль у вас на стороне, это внезапно не скомпрометирует его данные, потому что я все еще не могу войти в систему с использованием этого Информация. Секрет пользователя управляется сторонним провайдером, а не вами.

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

Answer 2

Зачем тогда использовать членство в asp.net? На самом деле это не вписывается в то, что вы делаете, это сторонняя аутентификация. Может быть, вы могли бы взглянуть на проект dotnetopenid и примеры, поскольку они имеют классический пример сайта asp.net, который вы можете изменить для mvc? У них есть вики здесь Может быть, Google dotnetopenid MVC?