以模糊文本形式存储的密码，未加密

Question

一个应用程序in (但没有开发或实现)声称正在使用“可逆加密”将密码存储在数据库中。

我可以访问数据库表，并且能够计算出它们实际上只是模糊的，并且可以通过应用简单的映射来确定明文值。这似乎很糟糕，我担心是对的吗？推荐接下来的步骤？

编辑1:应用程序由A公司开发，由公司B (SaaS)为我们托管。“可逆加密”设置似乎是开箱即用的配置。不清楚更改设置会影响什么，但是表中99%的密码是用于登录应用程序本身，而与外部系统无关。不要求任何人知道其他人的密码。

Answer 1

我要做的第一件事是考虑系统是否需要“可逆加密”密码(如果它将密码发送到其他服务中，通常是肯定的，而不仅仅是在用户登录时验证密码，有时，如果某个重要客户需要这样做，则是肯定的，但他们也应该有适当散列的选项)。其次，由于您说的是“一个简单的映射”，我假设这实际上不是使用任何现代密码原语(AES、*fish、SALSA20等)，所以这绝对是您可以提交的安全漏洞。

查找安全联系人(电子邮件地址等)。应该有一个在网站的某处。如果你找不到，试着发电子邮件给security@company.domain，或者直接联系他们的支持线，并要求提供一个安全联系。

请注意，任何形式的可逆加密，无论其密码如何更新或其密钥如何强，都存在密钥存储问题:程序需要访问密钥，这意味着任何能够访问该程序本身的人几乎都可以解密数据。然而，使用真正的加密仍然需要改进：

• 真正的加密，即使使用硬编码的密钥，也将防止任何不知道密钥的人在访问DB时逆转加密。听起来他们现在甚至都不满足-很低的标准。
• 正确地完成，键应该是唯一的每个实例的应用程序。访问其他人的数据库不应该泄露任何信息，即使您知道软件的副本/实例所使用的加密密钥。
• 密钥应该存储在尽可能难以访问的位置。理想情况下，它将存储在实际不可提取的地方(如HSM)，该应用程序能够请求任意字符串的加密和解密，但不允许其他软件访问HSM。至少，密钥需要与DB分离，这样，即使是具有完全、不受约束的DB访问权限的攻击者，也无法在系统的其他部分找到新的漏洞。

听起来你已经很清楚为什么他们应该使用一个缓慢的密码哈希函数，而不是任何类型的可逆加密。即使他们需要对某些密码/API密钥进行加密(用于访问外部服务，而不是对本地用户进行身份验证)，他们也应该仅对这些秘密使用加密，并对用户密码使用安全密码哈希算法。

如果供应商不让步-说这不是安全漏洞，或者他们不在乎，或者只是拒绝回应-给他们一些时间，然后(国际海事组织)，是时候升级了。如果可能的话，试着说服你的公司取消合同，这通常是最简单的手段。如果你做不到的话，我会更喜欢点名和丢脸。当事情可能影响到他们的底线时，公司通常更有可能做出反应，而不好的宣传也能做到这一点。像https://plaintextoffenders.com/这样的网站，或者仅仅是在社交媒体上公开接触(特别是，或者至少提到一些知名的安全人物)，都可以帮助传播这个消息。

很明显，最后一部分并不是没有风险的。在使用术语上可能有一些关于“逆向工程”软件的问题，尽管我认为这种“密码分析”的水平根本不重要，但我不是律师。如果您必须绕过任何尝试的安全措施来阻止您进入DB --输入管理员/admin的用户名/密码可能会计算在内，尽管在您控制的系统上从纯文本配置文件中复制DB连接字符串并不重要--那么这就增加了他们认为值得律师参与的风险。一家聪明的公司不会这么做的--对那些试图负责任地报告安全问题的人实施法律，是让整个安全社区对你发火的好办法，我们中的一些人对大公司(其他公司是黑客主义者)怀恨在心，提出产品建议--但一家聪明的公司不会让事情发展到这么远。在采取任何步骤之前，除了只向供应商报告问题外，特别是如果您有任何涉及公司名称的概念，您可能需要与法律部门联系。不过，我不是律师，这也不是法律意见。