Очень простая аутентификация с использованием сеанса в asp.net MVC - это безопасно?

Question

ASP.NET Identity чрезвычайно сложна и перегружена для того, что мне нужно в приложении ASP.NET MVC 5. Хранение вещей - это хороший принцип ИМХО.

Когда пользователь входит в систему, я просто использую Dapper для поиска по электронной почте & пароля в базе данных (хеширование &).

Затем я установил сеанс ["userID"] = user.Id // из базы данных.

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

Если пользователь является администратором, я также просто установил Session ["admin"] = true;

Я затем создать простой класс, который наследуется от AuthorizeAttribute:

public class MyAuthorizeAttribute : AuthorizeAttribute 
{ 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    { 
     if (httpContext.Session["userID"] == null) 
      return false; 
     else 
      return true; 
    } 

    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext) 
    { 
     filterContext.Result = new RedirectResult("~/Account/Login"); 
    } 
} 

так что я могу использовать атрибуты авторизации на моих контроллерах:

[MyAuthorize] 
public ActionResult MyController() 
{ 
... 
} 

Является ли это безопасно? Есть ли какие-то шаги, которые мне не хватает, чтобы защитить это - если да, то что?

Что-то не так с этим, что он не работает?

Сессия способна это сделать? Если не то, что будет &, то какой будет лучший способ (это так же просто)?

Answer 1

Прежде всего, я не согласен с вашими комментариями о сложности. До сих пор ASP.Net Identity - это самая полная и хорошо составленная структура аутентификации/авторизации для .Net. Он превосходит всех предшественников с множеством возможных точек расширяемости. Если вы считаете, что это очень сложно, подумайте о безопасности в целом - это очень сложный домен с высокими рисками. Рамка идентичности фактически упрощает и скрывает много сложностей, поэтому вам не нужно иметь дело с этим. Если вы все еще настаиваете, что это сложно ... ну, да, разработка программного обеспечения - сложный бизнес. Вычисление вообще сложное ... ну, жизнь сложная!

В любом случае, вернемся к вашему решению. Я вижу как минимум один главный недостаток вашего решения. Вы сохраняете своих пользователей в сеансе cookie сеанса. Вы предлагаете сессию очень долго жить. Это означает, что cookie сеанса не изменяется в течение длительного времени. Поэтому, если кому-то удалось каким-то образом получить доступ к сеансу, у них будет очень длинное окно возможности злоупотреблять доступом к вашей системе как кто-то другой. Идентификация решает эту проблему, поворачивая файл cookie - по умолчанию каждые 30 минут изменяется значение cookie авторизации. Поэтому, если вы получите вчерашнее значение cookie вчерашнего дня - это не будет хорошо. Вы также можете уменьшить это значение до пары минут или даже обновить значение cookie для каждого запроса.

Тогда вам нужно будет подумать о истечении срока действия сеанса и управлении. Сначала это будет память - для каждого пользователя, зарегистрированного за последние 30 дней, вам придется поддерживать живую сессию на своем сервере. Представьте, что тысяча пользователей вошли в систему ... Я не знаю, сколько данных у вас будет на сеансе пользователя, но при достаточном использовании вы начнете сталкиваться с проблемами памяти. Затем, если вы захотите загрузить балансировку серверов, вам придется ввести липкий сеанс. Также, когда ваш сервер перезагрузится, все ваши пользователи потеряют свои сеансы (я использовал такую ​​систему - это ужасно).

Следующее, что вам нужно будет позаботиться о нескольких пользовательских входах - что произойдет, когда один и тот же пользователь войдет в систему из двух разных браузеров? Что происходит с сеансами пользователя, когда пользователь меняет пароль - как он выходит из других браузеров?

Я не делал ужасной работы с сеансом, поэтому я не уверен, как создается cookie сеанса. Но глядя на documentation (Session Identifiers section) sessionId сохраняется в файле cookie. И вы предлагаете поместить User.Id в этот cookie сеанса. Это означает, что если User.Id известен злоумышленнику, тогда они могут войти в систему как пользователь в любое удобное для них время. Чтобы смягчить это, вам придется придумать способ скрыть идентификатор пользователя внутри сеанса и использовать какой-то идентификатор корреляции, и даже тогда вы не избегаете того факта, что когда созданный идентификатор корреляции будет длиться всю сессию - 30 дней. Говоря о сложном решении?

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

• Validate вновь зарегистрированные электронные письма
• 2-аутентификация
• Социальных логины
требование к прочности
• Пароля
• Имени пользователя/адрес электронной почты требование уникальности
• Блокировка пользователя
• СМЯГЧАТЬ обмен пароль
• Сброс пароля по электронной почте

Список не является исчерпывающим - всего лишь что-то от верхней части головы.