Подтвердить что ты не робот

Объект 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(строка, строка) ' устарел: "Рекомендуемая альтернатива - использовать Членство API, например Memberhip.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 и новой (но довольно ужасной) модели аутентификации на основе OWIN, приведенный выше код более чем достаточен.

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

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

4b9b3361

Ответ 1

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

К вашему второму пункту, нет никакого отношения между любым из этого и OWIN.

Надеюсь, что это очистит!

Ответ 2

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

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

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

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

Вот еще одна справочная информация о безопасности OWIN midddleware, реализованная Microsoft.