我知道还有其他关于密码存储和加密的帖子，但我的问题略有不同。
我在一个密码管理器网站上工作，为了好玩。我想知道我的这个想法有多安全。
因此，很明显，用户存储的每个密码都是使用AES-256加密的，并将其主密码作为密钥和随机生成的salt。此外，主密码是使用Bcrypt加密的，但在之前，它会使用漩涡之类的东西进行大约100000次哈希，以增加登录时的压力。
如果用户决定不想在每次请求网站密码时输入密码，则程序无法解密密码并自动填充，因为解密存储的密码需要主密码。
我的一个想法是将密码存储在用户当前会话中，但这不是一个好主意，因为我试图假设攻击者已经破坏了我的服务器，正在下载数据库并四处窥探。
另一种方法是使用100000次散列密码作为AES-256加密的密钥，并将该散列存储在会话中。这比以纯文本存储要好，但如果攻击者能够从会话中获得信息，他/她仍然可以解密存储的密码。
有更好的方法吗？还是这是一场失败的希望之战，攻击者在我登录时不会进入？
如果您想要完全安全，密码的存储方式应该是，即使服务器也无法在没有用户输入的情况下解密它们，因此主密钥只能存储在客户端。
由于你不希望它存储在会话中，你可以将其存储在cookie客户端，但最重要的是，如果入侵者侵入了你的服务器并可以修改其代码，为了使网站正常运行，根据定义，如果密码在服务器端解密，他们必须能够获得密码。
因此，如果您愿意，您可以编写一个javascript/客户端应用程序，该应用程序将接收给定用户的AES加密字符串，并使用用户输入的主密码在客户端对其进行解密。这样做的问题是，在给用户加密密码之前，你必须有一条次要的信息，或者如果每个人都要求，你必须愿意给他们加密密码。这里还有一个额外的隐藏复杂性，如果你的入侵者能够更改服务器上的代码，理论上，他们可以将其从运行客户端更改为运行服务器端，从而获得解密的密码，或者他们可以修改客户端javascript，用解密的密码进行AJAX调用。
此外，主密码是使用Bcrypt加密的，但在之前，它会使用漩涡之类的东西进行大约100000次散列，以增加登录时的压力
没有必要这样做，只需增加Bcrypt的强度参数，以增加他们尝试登录的时间。Bcrypt内置了密钥拉伸功能。
不幸的是，您必须在安全性和便利性之间做出选择。
使用基于硬件的解决方案可能会使获取密钥变得更加困难，但最终，您的应用程序必须能够以明文形式检索存储的密码。如果攻击者完全控制了服务器，则不会阻止他执行完全相同的步骤。
为了最大限度地提高安全性，即使是服务器也不一定能够解密存储的密码，只有当密钥留在客户端时，这才有可能。您可以为客户端编写一个应用程序，并仅使用服务器来存储加密的密码存储库。
顺便说一句，BCrypt算法已经进行了密钥拉伸，因此没有必要添加额外的哈希回合。在这种情况下，更好的解决方案是增加成本因素。