目前我们正在开发一个小型应用程序，我们在基于Rails的基于JS的图形编辑器（想象一下this的加速版本）中存储了大量JSON数据后端。我们希望允许用户存储加密的数据（AES，RSA，无论如何），因为我们应用程序维护人员无法解密我们的数据库中的内容 - 当然，这也是一个强密码。没有用户帐户管理，没有。人们只能通过秘密链接创建和编辑他们的图表，仅此而已。
在编辑或保存当前状态之前，需要输入密码来加密/解密来往DB的图形。现在，我们现在面临的概念性问题如下：
我们在整个会话期间存储密码吗？如果不是，用户每次刷新浏览器或想要将其图形的当前状态保存到DB中时都必须输入密码。不舒服...
如果 - 从软件工程的角度来看 - 这是适用的：哪里这种信息是否一般存储？我们有什么选择除了饼干？
如果是这样 - 我们是否必须存储普通密码，或者是否有办法以某种方式加密密码，以便在被盗cookie时攻击者将面临更难的游戏获取密码？
答案 0 :(得分：1)
很多时候，安全是一种平衡，就是这种情况。
考虑到您的要求（没有用户管理后端的webapp），我认为您有两种选择：
您不存储密码，但用户体验更差。如您所述，任何刷新都需要用户再次输入密码。
您存储密码客户端（请参阅下面的方法），一个合理的位置是SessionStorage。这样它很舒服，并且可以像任何用户所期望的那样工作：在用户关闭浏览器之前它“正常工作”，但之后却没有。显然，这具有密码以某种形式存在于浏览器中的真正风险。它适用于任何Javascript（考虑xss），你不能阻止它被缓存到磁盘（无论你做什么，考虑冬眠电脑等）。一般来说，这是一个反模式，但并不是那么简单。安全决策应基于风险。
这是您必须根据您的用例特定风险做出的决定。什么是数据，攻击的可能性是什么（你为了合理保证你的代码是安全的，你做了什么），影响是什么（如果密码丢失会丢失什么，包括声誉损失等等） ）。如果他们不得不一直输入密码，您的用户是否真的讨厌该产品？只有你能解决这些问题。
加密客户端上的密码没有意义，thr攻击者会拥有解密它的一切。但是，对它进行散列可能会有一些好处，起初可能有点令人惊讶。如果你实际上没有存储密码而是某种转换，那么无论你存储什么都 密码，所以看起来它没有意义。它仍然存在的原因是因为人们倾向于重复使用密码，所以如果你从密码中获取一个密钥，比如说PBKDF2并将其存储为密钥，那么攻击者最好不能拥有来自浏览器的实际密码（但是如果有妥协，他们仍然可以访问数据，比如xss）。
因此，如果（并且仅当）您接受上述存储风险以及与javascript加密相关的风险，您应该