我在 AppEngine 上运行 REST 服务(可能不相关)。每个 REST 请求都附带一个用户 ID 和密码，在每个请求开始时，我都会对密码进行哈希处理，以查看它是否与我的记录匹配，然后再继续。
这在理论上运作良好，但在实践中我收到了来自用户的突发请求 - 每秒 4 或 5 个。 BCrypt 需要 500 毫秒来哈希每个请求的密码!真是浪费!
显然，我不想优化 BCrypt 时间。是否有缓存哈希的标准做法？ memcache 是否是存储最近哈希密码及其哈希表的安全位置？我想那时我不妨将用户的纯文本密码存储在 Memcache 中。我喜欢执行 3 毫秒的内存缓存查找，而不是 500 毫秒的哈希，但安全性至关重要。实现某种 session 抽象会更有意义吗？
感谢您的建议!
编辑额外上下文:这是一个成绩簿应用程序，用于存储敏感的学生数据(成绩)。教师和学生从任何地方登录，包括通过 wifi 等。每个成功的请求都通过 https 发送。
最佳答案
REST API 的通常经验法则是让它们保持完全无状态，但是，与 goto 一样，时间和地点取决于您的要求。如果您不反对让客户端存储一个临时 session key (您只需要偶尔重新生成)，那么您可以尝试一下。
当客户端发出请求时，检查他们是否发送 session key 变量以及用户 ID 和密码。如果不是，则根据当前服务器时间和密码生成一个，然后将其传回客户端。将其及其创建时间存储在您自己的数据库中。然后，当客户端发出包含 session key 的请求时，您可以通过直接将其与数据库中存储的 session key 进行比较来验证它，而无需哈希。只要每隔几个小时使 key 失效一次，就不会有太大的安全问题。不过，如果您当前以明文形式发送密码和用户 ID，那么您已经遇到了安全问题。
关于web-services - 针对多个请求的高效密码散列，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8376101/