我在AppEngine上运行REST服务（可能不相关）。每个REST请求都附带一个用户ID和密码，并且在每个请求开始时，我都会对密码进行哈希处理，以便在继续操作之前查看它是否与我的记录匹配。
这在理论上运作良好，但实际上我会收到来自用户的请求 - 每秒4或5次。它需要BCrypt 500ms来为每个请求散列密码！多么浪费！
显然，我不想优化BCrypt时间。缓存哈希是否有标准做法？ memcache是一个安全存储最近哈希密码及其哈希表的安全地方吗？我想在那时我也可以将用户的纯文本密码存储在Memcache中。我喜欢做3ms的memcache查找而不是500ms的哈希，但安全性是至关重要的。实现某种会话抽象会更有意义吗？
感谢您的任何建议！
编辑额外的上下文：这是一个存储敏感学生数据（成绩）的成绩簿应用程序。教师和学生从任何地方登录，包括通过wifi等。每个成功的请求都通过https发送。
答案 0 :(得分：2)
使用REST API的常用经验法则是让它们保持完全无状态，但是，与 goto 一样，根据您的要求，有时间和地点。如果您不反对让客户端存储临时会话密钥的想法，您只需要偶尔重新生成，那么您可以尝试一下。
当客户端发出请求时，请检查他们是否正在发送会话密钥变量以及用户ID和密码。如果不是，则根据当前服务器时间和密码生成一个，然后将其传递回客户端。将其与创建时间一起存储在您自己的数据库中。然后，当客户端发出包含会话密钥的请求时，您可以通过直接将其与存储在数据库中的会话密钥进行比较来验证它，而无需使用哈希。只要您每隔几个小时使密钥无效，就不应该担心安全问题。然后，如果您当前正在以明文形式发送密码和用户ID，那么您已经遇到了安全问题。
答案 1 :(得分：1)
根据您当前的方法，最好的选择是在memcache中保留尝试密码到其加密形式的映射。如果您担心在memcache中存储明文密码，请使用尝试密码的md5或sha1哈希作为密钥。
额外的步骤并非真的有必要。存储在memcache中的项目不会泄漏给其他应用程序。