Безопасен ли этот метод аутентификации?

Question

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

В значительной степени, это логика, которую ябудет:

Регистрация:

1. Пользователь отправляет свое имя пользователя и пароль через HTTPS.
2. Пароль будет зашифрован с использованием SHA1 и сохранен в базе данных.

Логин:

1. Пользователь предоставляет имя пользователя и пароль через HTTPS.

2. Пароль преобразуется в SHA1 и сравнивается с паролем в базе данных.

   ЕСЛИ пароли совпадают

   the users id will be stored in their session under the user_id key.
   

   ELSE

   the user will be directed back to the login page
   

Логика, выполняемая перед страницами, требующими аутентификации:

1. Сессия пользователя будет проверена, чтобы увидеть, сохранен ли его идентификатор

   ЕСЛИ идентификатор пользователя найден в его сеансе

    user is permitted to view the page
   

   ELSE

    user is given a 404 response.
   

Так насколько это безопасно?Я что-то упускаю, что мне следует делать?

Спасибо за ваш вклад.

ОБНОВЛЕНИЕ:

Некоторые люди хотели, чтобы среда, которую я использую - я работаю всреда сервлетов Java.Насколько я понимаю, java хранит сессии на сервере и просто сохраняет sessionid в файле cookie.Что заставляет меня задуматься, есть ли в HttpSession java меры, обеспечивающие невозможность кражи чьего-то сеансового ключа?

Answer 1

Эта часть, кажется, в порядке, кроме того, что уже сказал Мэтью. Некоторые вещи, о которых вы также должны подумать:

• защити свою страницу
  • Межсайтовый скриптинг
  • SQL-инъекция
• убедитесь, что файл cookie сеанса только для HTTPS

Answer 2

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

Answer 3

вам придется заставлять людей менять пароли, которые они забывают, поскольку вы не сможете отправить им их пароли.

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

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

Вы можете добавить капчу, чтобы предотвратить скриптсделайте грубую попытку попробовать общие пароли.

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