Каким образом passport.js deserializeUser расшифровывает хешированные данные сеанса? - PullRequest
Новая
       25

Каким образом passport.js deserializeUser расшифровывает хешированные данные сеанса?

1 голос
/ 26 июня 2019

После того, как пользователь войдет в систему, отправив сообщение POST, чтобы сказать / войти в систему, к паспорту будет прикреплен файл cookie сеанса, чтобы установить постоянный сеанс. Это делается с помощью функции serializeUser. Затем express-session будет использовать эту функцию для генерации хеша (вычисленного с использованием HMAC) и отправит его поверх.

При следующем запросе passport каким-то образом удается расшифровать хешированную строку с помощью функции deserializeUser и извлечь из нее пользовательские данные. Как это возможно, если express-session действительно хеширует строку? Разве хеши не являются односторонними функциями? И если экспресс-сессия не хэширует строку, не является ли это уязвимостью безопасности?

1 Ответ

0 голосов
/ 27 июня 2019

Приложение может предоставить serializeUser и deserializeUser.

Приложение должно иметь возможность безопасно выполнять deserializeUser, потому что они могут проверять каждый полученный им хэш (установить и прочитать с помощью промежуточного программного обеспечения для паспорта через request.session; я думаю, что ответственными частями могут быть эти: https://github.com/expressjs/session/blob/master/index.js#L160 и https://github.com/jaredhanson/passport/blob/master/lib/sessionmanager.js#L18-L25 (или на последнем поддерживаемом форке, https://github.com/passport-next/passport/blob/master/lib/sessionmanager.js#L21-L28)) против карты, которую они сохранили в своей локальной базе данных / файле / сервисе, предварительно связав и сохранив такие хеши пользовательских сеансов вместе с именем пользователя (и / или другой конкретной информацией о сеансе).

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

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

...