Лучшие практики входа пользователей в ASP.NET

Question

Я хочу создать систему входа в систему с использованием ASP.NET (MVC).

В интернете я нашел несколько плохих примеров использования SQL в событиях Click. Другая информация указывает на встроенного поставщика членства ASP.NET.

Тем не менее, я хочу кататься самостоятельно. Я не хочу использовать встроенный поставщик членства, так как он работает только на MS SQL, и мне не нравится идея иметь несколько внешних таблиц в моей базе данных.

Возможно, я мог бы что-то придумать, но мне нужно несколько указателей в правильном направлении. Это не обязательно должен быть высокий уровень безопасности, а просто обычный уровень безопасности.

И у меня есть несколько прямых вопросов:

1. Кажется, что во многих системах идентификатор сеанса хранится в пользовательской таблице. Я предполагаю, что это связывает сеанс с пользователем, чтобы предотвратить угон. Проверяйте это каждый раз, когда пользователь заходит на страницу? И что мне делать, если сессия истекает?

2. Хэширование, соление, что это делает? Я знаю о хешировании MD5, и я использовал его раньше. Но не солить.

3. Рекомендации по использованию файлов cookie?

Answer 1

Я не знаю о лучших практиках, но я могу рассказать вам, что я делаю. Это не высокотехнологичная безопасность, но она делает свою работу.

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

В классе FormsAuthentication есть методы, доступные для вас, такие как SetAuthCookie и RedirectFromLogin. они установят cookie и отметят их как аутентифицированных. Файл cookie, используемый asp.net, зашифрован. Хотя я не могу говорить о его уровне безопасности, но он довольно широко используется.

В моем классе я делаю проверку пароля и использую FormAuth для обработки остальных:

if(SecurityHelper.LoginUser(txtUsername.Text, txtPassword.Text))
{    
    FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, true);
}

Answer 2

Соль - это практика добавления нешифрованной строки символов в то, что хэшируется. Предположим, mySalt = abc123 и мой пароль passwd. В PHP я бы использовал hashResult = md5(mySalt + password).

Предположим, строка перехвачена. Вы пытаетесь найти совпадение со строкой, но в итоге вы получаете совпадение, потому что пароль был засолен перед зашифрованием Просто помните, что то, что вы используете для соли, должно быть непрерывным на протяжении всего применения. Если вы солите пароль перед хранением, вы должны сравнить хешированный, соленый пароль с БД.

Answer 3

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

Если вам нужно использовать другое хранилище данных, я согласен с axel_c, если я собираюсь свернуть свой собственный, то я напишу поставщика членства в соответствии со спецификацией MS. Это сделает код более понятным для любых разработчиков, следующих за вами.

Answer 4

Вы можете реализовать своего собственного поставщика членства с помощью инфраструктуры ASP.NET, см. Документы MSDN для класса MemberShipProvider .

Answer 5

Вы можете использовать встроенный поставщик членства SQL - и вы можете настроить выделенную базу данных «пользовательского доступа», если вы не хотите, чтобы таблицы членства .Net в вашей базе данных - просто укажите это в строке подключения. *

Преимущество модели провайдера на уровне приложения, код не зависит от того, какое конкретное хранилище аутентификации вы использовали.

На сайте asp.net есть хорошая серия учебных пособий:

текст ссылки

Answer 6

Недостатком поставщика членства от Microsoft является то, что вы не можете использовать его в доменном подходе. Если вы хотите, вы можете создать свой собственный пользовательский объект со своим собственным хэшем пароля и при этом использовать cookie-файлы аутентификации, предоставляемые Microsoft. Использование этих файлов cookie аутентификации означает, что вам не нужно самостоятельно управлять идентификаторами сеанса.

public void SignIn(User user)
        {
            FormsAuthentication.SignOut();
           var ticket = new FormsAuthenticationTicket(1, user.UserName, DateTime.Now.AddMinutes(30), expires, alse, null);
            var encryptedTicket = FormsAuthentication.Encrypt(ticket);
            var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
            {
                Expires = ticket.Expiration
            };

            httpContextProvider.GetCurrentHttpContext().Response.Cookies.Add(authCookie);
        }

    public void SignOut()
    {
        FormsAuthentication.SignOut();
    }

Я использую свой собственный пользовательский объект и таблицы. Я храню хеши паролей в пользовательской таблице с уникальной солью для каждого пользователя. Это безопасно, легко реализовать и будет соответствовать вашему дизайну. Ваша таблица базы данных не будет загрязнена хламом поставщика членства в Microsoft.

Answer 7

Я бы избежал всей проблемы и использовал бы openid. Доступна библиотека, которую вы можете использовать напрямую. Вот ссылка на пост в блоге о том, как поставить это на место