目前我们正在开发一个小型应用程序，我们在基于 Rails 的后端中存储来自基于 JS 的图形编辑器(想想 this 的增强版)的一堆 JSON 数据。我们希望允许用户存储加密数据(AES、RSA 等)，作为应用程序维护者，我们不可能解密我们数据库中的内容——当然要给定一个强密码。没有用户帐户管理，什么都没有。人们只能通过 secret 链接创建和编辑他们的图表，仅此而已。
在编辑或保存当前状态之前，需要密码来加密/解密进出数据库的图形。现在，我们现在面临的概念性问题如下:
我们是否在整个 session 期间存储密码？否则，用户每次刷新浏览器或想要将图形的当前状态保存到数据库时都必须输入密码。不舒服……
如果 - 从软件工程的 Angular 来看 - 这是适用的:这种信息通常存储在哪里？除了 cookie，我们还有哪些选择？
如果是这样 - 我们是否必须存储明文密码，或者有没有办法以某种方式加密密码，以便在 cookie 被盗的情况下，攻击者将面临更困难的游戏获取密码？
最佳答案
很多时候，安全是一种平衡，这就是一个例子。
考虑到您的要求(没有用户管理后端的 webapp)，我认为您有两个选择:
您不存储密码，但用户体验会变差。如您所说，任何刷新都需要用户再次输入密码。
您在客户端存储密码(见下文如何操作)，一个合理的位置是 SessionStorage。这样它很舒适并且可以像任何用户期望的那样工作:它“正常工作”直到用户关闭浏览器，但之后就不会了。显然，这具有密码以某种形式存在于浏览器中的非常真实的风险。它可用于任何 Javascript(考虑 xss)并且您无法阻止它被缓存到磁盘(无论您做什么，请考虑让 pc 休眠等)。一般来说，这是一种反模式，但并没有那么简单。安全决策应基于风险。
这是您必须根据您的用例特定的风险做出的决定。数据是什么，受到攻击的可能性有多大(你做了什么来合理保证你的代码是安全的)，影响是什么(如果密码丢失，你会失去什么，包括名誉损失之类的事情) ).另外，如果用户必须一直输入密码，他们真的会讨厌这个产品吗？只有您可以回答这些问题。
在客户端加密密码是没有意义的，攻击者将拥有解密它的一切。然而，对它进行哈希处理可能会有好处，一开始可能有点令人惊讶。如果您实际上不存储密码而是进行某种转换，那么无论您存储什么，都将 为密码，因此看起来没有意义。它仍然存在的原因是因为人们倾向于重复使用密码，所以如果你从密码中派生出一个 key ，比如 PBKDF2 并将其存储为 key ，那就更好了，攻击者无法从浏览器中获得实际密码(但是如果存在妥协，比如 xss，他们仍然可以访问数据。
因此，如果(且仅当)您接受上述存储风险以及与 javascript 加密相关的风险，您应该
- 使用适当的 key 派生函数从用户密码派生 key ，例如 pbkdf2
- 将该 key 作为加密 key 存储在 SessionStorage 中
关于javascript - 前端侧加密: Where to store password throughout session?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49406435/