我知道还有其他关于密码存储和加密的文章，但我的问题略有不同。

我在一个密码管理器网站上工作，为了好玩。想知道我的想法有多安全。

所以很明显，用户存储的每个密码都是使用aes-256加密的，其主密码作为密钥，随机生成一个salt。另外，主密码是使用bcrypt加密的，但在使用诸如whirlpool之类的东西之前，它会被散列100000次，以增加试图登录时的压力。

如果用户决定每次请求站点密码时都不想输入密码，则程序无法解密密码并自动填充，因为解密存储的密码需要主密码。

我的一个想法是将密码存储在用户当前会话中，但这并不是一个好主意，因为我正在尝试这样做，假设攻击者已经破坏了我的服务器，正在下载数据库并四处窥探。

另一个方法是使用100000次散列密码作为AES-256加密的密钥，并将散列存储在会话中。这比以纯文本形式存储要好，但如果攻击者能够从会话中获取信息，那么它仍然可以让攻击者解密存储的密码。

是否有更好的方法来解决这个问题，或者这是一场希望之战，当我登录时攻击者不会进入？

如果您想要完整的安全性，密码的存储方式应该是这样的：即使服务器也不能在没有用户输入的情况下解密它们，因此主密钥只能存储在客户端。

由于您不希望将其存储在会话中，因此可以将其存储在cookie客户端，但底线是，如果入侵者破坏了您的服务器并可以修改其代码，为了使站点正常工作，根据定义，如果密码解密发生在服务器端，则他们必须能够获取密码。

因此，如果您愿意，您可以编写一个javascript/客户端应用程序，它将接收给定用户的AES加密字符串，并使用用户输入的主密码对客户端进行解密。问题是，在你给用户他的加密密码之前，你必须有第二条信息，或者如果他们要求，你必须愿意给每个人，每个人的加密密码。这里还有另外一个隐藏的复杂性，如果入侵者能够更改服务器上的代码，他们理论上可以将其从运行客户端更改为运行服务器端，从而获得这些解密的密码，或者他们可以修改客户端javascript以使用解密的密码进行Ajax调用。

Also the master password is encrypted using Bcrypt, but before hand it is hashed some 100,000 times using something like whirlpool, to increase strain when trying to login

号

不需要这样做，只需增加bcrypt的strength参数，以增加尝试登录时的时间。Bcrypt内置关键拉伸功能。

不幸的是，您必须在安全性和方便性之间做出选择。

有人可能会使获取密钥变得更加困难，例如使用基于硬件的解决方案，但最终在某个时刻，您的应用程序必须能够以纯文本形式检索存储的密码。如果攻击者对服务器拥有完全控制权，没有什么可以阻止他执行完全相同的步骤。

为了达到最大的安全性，即使是服务器也不能解密存储的密码，而且只有在密钥保留在客户端时，这才是可能的。您可以做的是为客户机编写一个应用程序，并且只使用服务器来存储加密的密码存储库。

顺便说一句，bcrypt算法已经进行了键拉伸，因此不需要添加额外的哈希循环。在这种情况下，更好的解决方案是增加成本因素。