Обеспечение основанной на cookie аутентификации
gcc испустит предупреждения при нарушении спецификаций исключения. То, что я делаю, должно использовать макросы для использования спецификаций исключения только в компиляции режима "линта" явно для проверки, чтобы удостовериться, что исключения соглашаются с моей документацией.
4 ответа
На большинстве веб-сайтов это делается для аутентификации использования и в случае успеха они отправляют браузеру cookie для хранения и отправки любых последующих запросов. Если злоумышленник смог получить токен (до истечения срока его действия), он сможет выдать себя за пользователя.
По этой причине процесс cookie и аутентификации всегда должен выполняться через сеанс https. Единственный реальный способ, которым злоумышленник должен получить cookie, - это перехватить его на компьютере конечного пользователя, и если они смогут это сделать, они, вероятно, смогут установить регистратор нажатий клавиш и в любом случае получить пароль пользователя.
Как какой токен использовать, не имеет значения, если он достаточно псевдослучайно, чтобы злоумышленник мог его угадать с вычислительной точки зрения. Сам пользуюсь GUID. если вам нужна дополнительная информация в cookie, помимо идентификатора сеанса, вы можете добавить к нему GUID, а затем, возможно, зашифровать или зашифровать его только для подхода с поясом и скобками.
Лучший способ - сохранить идентификатор сеанса в качестве значения cookie.
Каждый раз, когда пользователь входит в систему, вы создаете запись в базе данных или другом хранилище сеансов со случайным идентификатором сеанса. Поместите идентификатор в файл cookie. Когда вы увидите файл cookie позже, вы сможете получить всю информацию о пользователе из базы данных.
Этот подход имеет следующие преимущества.
- Он очень безопасен. Идентификатор сеанса - это просто случайное число. Вам не нужно беспокоиться о взломанном ключе или соли.
- Cookie можно легко отозвать с сервера. Все, что вам нужно сделать, это удалить запись сеанса, и это сделает идентификатор бесполезным.
- Значение cookie может быть очень коротким.
Если это не сработает, попробуйте шифрование. Хеш был бы моим последним выбором. Сам по себе хеш бесполезен. Вы должны хранить идентификатор пользователя и другую информацию в другом файле cookie в открытом виде. В итоге вы раскрыли информацию о пользователе.
Два способа:
- Зашифровать его с помощью симметричного алгоритма (AES).
Это хорошо, потому что позволяет вам расшифровать его; но можно возразить, что вам не нужно его расшифровывать (в зависимости от того, что еще вы там храните).
- Хеш и подпись . Опять же, здесь используется закрытый ключ, поэтому, даже если кто-то знает точное содержимое, он не может воспроизвести хэш, потому что ему нужен закрытый ключ.
Я бы, вероятно (и ранее) выбрал вариант №1.
почему бы не сохранить только хеш в куки или любое другое псевдослучайное число? Затем проверьте базу данных, чтобы получить идентификатор пользователя.
Прочее: Сделайте cookie только http, т.е. не может быть установлен с помощью javascript Если это вариант, сделайте так, чтобы он передавался только с данными https