Объект FormsAuthentication устарел [с использованием MVC5]

Я использую следующий код на сайте MVC5:

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel loginModel) {
    if (ModelState.IsValid) {
        var authenticated = FormsAuthentication.Authenticate(loginModel.UserName, loginModel.Password);
        if (authenticated) {
            FormsAuthentication.SetAuthCookie(loginModel.UserName, true);
            return RedirectToAction("AdminPanel");
        }
        ModelState.AddModelError("", "The username and password combination were incorrect");
    }
    return View(loginModel);
}

Что выдает следующее предупреждение:

System.Web.Security.FormsAuthentication.Authenticate(string, string)» устарела: «Рекомендуемой альтернативой является использование API членства, например Membership.ValidateUser. Дополнительные сведения см. на странице http://go.microsoft.com/fwlink/?LinkId=252463.'

Сначала отказ от ответственности — я один из тех разработчиков, которым нравится быть в курсе событий, и я предпочитаю полностью избегать предупреждений в VS. Однако в данном конкретном случае я использую чрезвычайно примитивную аутентификацию, которая поступает непосредственно из web.config следующим образом:

<authentication mode="Forms">
    <forms loginUrl="~/account/login" timeout="2880" slidingExpiration="true" name=".ASPXFORMSAUTH">
        <credentials passwordFormat="SHA1">
            <user name="MyUserName" password="a-big-long-password-hash"/>
        </credentials>
    </forms>
</authentication>

В этом проекте нет абсолютно никаких дополнительных требований к входу в систему - использование базы данных является излишним, и нет необходимости в распределенном входе; по сути, хранение деталей в web.config является наиболее идеальным решением, и, вероятно, для каждого приложения будет только один пользователь. Я, без сомнения, абстрагирую код аутентификации от контроллера (используя DI/IoC), но я все еще намереваюсь использовать объект FormsAuthentication для аутентификации по деталям в web.config.

Хотя я полностью осведомлен о провайдерах членства, DotNetOpenAuth и новой (но довольно ужасной imo) модели аутентификации на основе OWIN, приведенный выше код более чем достаточен.

Первый вопрос. Почему FormsAuthentication устарела, когда это вполне допустимый вариант использования? Я понимаю, что FormsAuthentication — это запечатанный черный ящик, его трудно протестировать, а код, стоящий за ним, зависит от домена, но в данном конкретном случае (где я хочу прочитать подробности непосредственно из раздела web.config) это кажется безумием. написать поставщика членства или пользовательскую службу проверки подлинности?

Второй вопрос. Если я что-то не упустил, новая модель OWIN предназначена для распределенной аутентификации и не подходит для ролевой системы безопасности уровня предприятия. Из многих сообщений в блогах, официальных документов и сообщений SO, которые я прочитал, также кажется, что это все еще неполно. Прав ли я в своих предположениях? Является ли OWIN будущим всех систем безопасности, или мне следует продолжать писать индивидуальные системы безопасности, более подходящие для нужд моих клиентов?


c# asp.net-mvc-5 owin forms-authentication dotnetopenauth
person Spikeh    schedule 11.01.2014    source источник

Ответы (2)


arrow_upward
6
arrow_downward

К вашему первому замечанию, мы устарели, потому что это крайне неадекватно современным стандартам безопасности. Он использует прямой хэш без итерации, а это означает, что любой, кто обращается к вашему Web.config, может легко выяснить, какими были исходные пароли. Но если вы готовы принять эти риски, вы, безусловно, можете продолжать использовать его в будущем. Просто отключите предупреждение и используйте исходный код.

Что касается вашего второго пункта, то между этим и OWIN нет никакой связи.

Надеюсь, это прояснит ситуацию!

person Levi    schedule 12.01.2014
comment
Спасибо за ответ, Леви. В таком случае, каков предпочтительный способ достижения простой аутентификации, такой как в моем примере? Знаете ли вы какие-либо официальные документы или статьи, предлагающие какие-либо альтернативы, или рекомендуемый способ реализации членства и ваших собственных алгоритмов хранения и хеширования? Я делал это много раз в более сложных системах, но я чувствую, что в данном конкретном случае это излишне. - person Spikeh; 13.01.2014
comment
Если вы чувствуете, что это излишне для этого конкретного экземпляра, игнорируйте предупреждение (или отключите его с помощью #pragma warning disabled). Вы можете продолжать использовать этот оригинальный метод, если он подходит для вашего сценария. Если вам нужно что-то более безопасное, вы можете использовать Crypto.HashPassword msdn.microsoft.com/en-us/library/ и Crypto.VerifyHashedPassword msdn.microsoft.com/en-us/library/ из System.Web.Helpers .dll сборки. - person Levi; 13.01.2014

arrow_upward
6
arrow_downward

OWIN — это не только безопасность. Это стандарт, определяющий интерфейсы между платформой приложений (ASP.NET MVC) и веб-сервером (IIS). Это новый уровень абстракции, определенный Microsoft для того, чтобы позволить разработчикам .NET писать приложения, не зависящие от хоста, то есть не зависящие от IIS.

Архитектура OWIN — это конвейер, состоящий из нескольких компонентов промежуточного слоя. В MVC5 безопасность была переписана с нуля как компонент промежуточного программного обеспечения OWIN. Если это не работает для вас, и вы хотите использовать собственную процедуру проверки пароля, вы можете реализовать собственное промежуточное программное обеспечение безопасности. Вот сообщение с описанием как это сделать.

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

Однако все, что упоминал Леви, остается в силе. Вы хотите быть осторожным со своим собственным механизмом хэширования/хранения и выбрать хороший алгоритм хеширования.

Вот еще немного справочной информации о безопасности OWIN промежуточное ПО, реализованное Microsoft.

person 0leg    schedule 13.01.2014