Безопасная аутентификация с ASP.net - PullRequest
1 голос
/ 12 марта 2012

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

        if (validateUser(form.Email, form.Password))
        {
            return signIn(form.Email);
        }

функция validateUser возвращает логическое значение.Затем выполните вход в систему следующим образом:

    public void signIn(string email)
    {
        FormsAuthentication.SetAuthCookie(nameOfUser, false);
    }

, что впоследствии позволит мне делать такие вещи для всех будущих запросов;

string userEmail = User.Identity.Name;
Profile p = Profile.getProfileFor(userEmail);

Это кажется слишком простым, чтобы быть безопасным!Есть ли что-то, что я здесь упускаю / какие-либо ослепительно очевидные угрозы безопасности?Или это в основном то, как это делается?

С уважением,

Майк

Ответы [ 3 ]

2 голосов
/ 12 марта 2012

Теоретически вы должны использовать HTTPS, чтобы избежать атак посредника, но это не то, что делается в коде.Также из вашего кода не очевидно, если вы хэшируете пароли, как и должно быть.

КСТАТИ. Соглашение .NET - использовать PascalCase для имен методов.

2 голосов
/ 12 марта 2012

С безопасностью можно сделать гораздо больше:

  • Зашифровать пароль
  • Записывать каждую попытку входа с IP-адресом для выявления атак
  • Используйте столбец целочисленных идентификаторов вместо электронной почты:

    Это сделает приложение более гибким и быстрым.

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

.

  • Кэшируйте личность
  • Используйте роли
1 голос
/ 12 марта 2012

Вот как это делается, правильно.

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

...