HTTP Запомнить меня аутентификация - PullRequest
2 голосов
/ 07 июня 2011

Я пытаюсь написать простой HTTP, запомни меня систему аутентификации для пользователей.

Мои пользователи могут быть представлены как таковые

{
"email" : "foo@bar.com",
"password" : "8EC41F4334C1B9615F930270A4F8BBC2F5A2FCD3" // sha1 hash of password
}

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

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

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

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

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

Учитывает ли этот подход какие-либо другие уязвимости?

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

Ответы [ 2 ]

1 голос
/ 07 июня 2011

Это, по сути, то, что делает большинство сайтов, когда вы входите в систему. Да, cookie должен содержать уникальный идентификатор «сессии» пользователя. Файл cookie должен быть в основном случайным. Вам решать, делать ли это постоянным в сеансах браузера.

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

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

0 голосов
/ 07 июня 2011

Точка зрения уязвимости одинакова! Кража файлов cookie и связанные с ними механизмы, однако браузеры теперь достаточно умны, поэтому не стоит об этом беспокоиться.

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

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

...