Эффективное хеширование паролей по нескольким запросам - PullRequest
2 голосов
/ 04 декабря 2011

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

Это работает хорошо, теоретически, но на практике яполучать пакеты запросов от пользователей - 4 или 5 в секунду.BCrypt 500ms хеширует пароль для каждого запроса!Какая трата!

Очевидно, я не хочу оптимизировать время простоя BCrypt.Существуют ли стандартные методы для кэширования хэшей?Будет ли memcache безопасным местом для хранения таблицы недавно хешированных паролей и их хешей?Я полагаю, что в этот момент я мог бы также хранить обычные текстовые пароли пользователей в Memcache.Я бы хотел сделать поиск в 3ms memcache вместо хеша 500ms, но безопасность имеет первостепенное значение.Есть ли смысл реализовывать какую-то абстракцию сеанса?

Спасибо за любой совет!

Редактировать для дополнительного контекста: это приложение для зачетных книжек, в котором хранятся конфиденциальные данные учеников (оценки).Учителя и студенты входят в систему из любой точки мира, в том числе через Wi-Fi и т. Д. Каждый успешный запрос отправляется через https.

Ответы [ 2 ]

2 голосов
/ 04 декабря 2011

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

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

1 голос
/ 05 декабря 2011

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

Дополнительный шаг на самом деле не нужен. Элементы, хранящиеся в memcache, не попадают в другие приложения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...