以纯文本形式存储数据库中的密码与客户需求

Question

我想称“在数据库中以纯文本形式存储密码”这是一个糟糕的实践......但我们的客户在他的应用程序中这样做了。他们希望我续订该应用程序。

我的观点：我想改变这一点......但由于这不是我们客户的需要，目前还不清楚。

您如何处理有关安全性的问题？从我的观点来看，很难向客户解释这些问题。

Answer 1

我认为“糟糕的做法”是轻描淡写的。 “不负责任”可能更准确。

如果用密码保护它是值得的，那么值得正确地做到这一点。以明文形式存储密码是一种令人尴尬的安全漏洞，等待发生。

如果“安全”在您的客户愿望的任何地方（我猜它是，因为有密码），他们隐含地要求一个像样的安全系统，其中包括正确处理密码。他们可能不会要求“密码被安全存储”（哈希和盐渍），因为他们不是专家;这就是他们雇用你的目的。

Answer 2

写一封简短，清晰，没有行话的正式信函，说明您的疑虑，并在您的专业意见中得出结论，应予以纠正。将它告诉客户中相当高的人。

如果他们选择忽略你的建议，那就是他们的特权。

（也请自己保留一封信。）

Answer 3

如果可以，现场演示效果很好。要求用户使用密码创建帐户（而不是他们通常使用的密码）。进入数据库并检索，并解释任何有权访问您数据库的人（通过许可或通过安全漏洞）都可以继续执行此操作。

Answer 4

永远不保留密码的最佳理由实际上是合法的。

有些法律，例如英国的“数据保护法”，其中规定必须采取合理措施保护敏感数据的安全。以明文形式存储密码显然会违反此规定，并且反过来可能会使您在违反安全规定时获得的任何赔偿保险无效。如果您不采取这种简单的措施，这可能会让您对大型责任诉讼持开放态度。

对于商务人士来说，你总是要谈论他们的口袋，并指出一小时工作来破解密码，并改变登录将花费他们相当于潜在成本的一小部分严重错误。

值得注意的是，如果有人设计的系统本身存在根本性缺陷，那么可能会出现错误的可能会导致此类敏感数据暴露指数更高。< / p>

除此之外，正如其他人所说，现场演示是好的。从数据库中取出随机的工作人员密码，并在其他系统上试用，在进入之前不必尝试很多。

Answer 5

切勿以明文形式存储密码。

我建议您阅读这些问题：

• How to best store user information and user login and password
• Best practices for storing database passwords
• Password Management Best Practices (soup to nuts, not just storage or generation)
• Salting Your Password: Best Practices?
• Is it ever ok to store password in plain text in a php variable or php constant?

如果您的客户对细节不感兴趣 - 只需实施即可。 （还提供正确的密码恢复程序）。对于作为程序员而言，这对你来说并不是什么大不了的事，但真正提高了安全性和安全性。您的产品质量。

如果他想知道你打算改变什么 - 向他解释。告诉他有关安全问题的信息，他会理解。另外一个现实的例子确实有助于打开顾客的眼睛：只需从他们的旧系统中检索他的密码，并告诉他对每个人来说是多么容易。

我一直这样做：如果我觉得在我的某个产品中安装一个安全功能很重要 - 我总是把它包括在内。它为您的产品质量增添了一大亮点，并为您提供了许多“你想到的所有事物”的时刻。

Answer 6

Bastanneu，你知道英文表达“盖你的**”吗？想象一下这种情况：

1. 您担心他们不关心安全问题，他们不想听到您的信息。无论如何你告诉他们，他们对任何改变说不。
2. 他们被黑了。
3. 他们问你为什么不提前说什么。

我建议您提前了解您的疑虑。并保持证明（签名信等）。

Answer 7

如果有意图的人有权访问数据库，您应该向客户解释登录是不安全的。如果应用程序在公司内部，可能不值得更改它。你必须分析它是否真的是一个价值，你只能通过与客户交谈来了解它。也许数据不是非常机密，并且拥有大量安全性并不是优先事项。所有这些都取决于软件目标以及数据库的位置以及客户希望其数据安全的内容。

Answer 8

我会解释他们所做的是不好的做法，并问他们是否希望你改变它。我建议不要在没有咨询的情况下做任何超出许可证的事情。

Answer 9

从严格的专业角度来看，你必须问自己是否会在以后将其作为一个问题摆出来（你是否有一个支持合同，如果一个劫持者从一个劫持DB？）

就个人而言，我不认为很难向某人解释为什么存储未加密的通行证是不安全的，但是，正如Daok指出的那样，你真的不必担心传递系统不要保存私密 - 秘密 - 魔法数据。

现在，为此目的使用加密似乎很容易，根据您使用的技术，它可能意味着只需要最轻微的编码工作和时间来完成它。

干杯队友！

Answer 10

演示和解释是最有用的，但当您说要“更新”应用程序时，您是使用文档，功能还是技术规范？

要求参与最终确定这些文件并将其包括在签字中是个好主意。

最终， 是对客户的需求，他们还没有意识到这一点。

Answer 11

在这种情况下，你必须正确地说明事情。明文密码不是你说的“坏习惯”。这是你被称为破碎的东西，这是根本无法完成的事情。您必须使您的合同取决于修复其密码存储，它不是可选的。这并不是说你不能就为什么不能做到这一点进行友好的讨论，但你必须明确表示你不会这样做，无论如何。

那么问题就变成了如何让业务人员相信它不是一个有效的解决方案。这也应该相当容易。找到决策者，并将它们带到您打开数据库查询浏览器的计算机上。输入查询“从凭证中选择密码，其中username ='DECISION_MAKERS_USERNAME'”，然后让决策者执行它（礼貌，不要像他们那样看屏幕）说明任何有数据库访问权限的员工都能够做这个。一般来说，我认为这样做会有所帮助，但是如果你需要做进一步的说服解释，大部分用户在应用程序之间共享密码，并且任何员工都可以闯入银行账户，电子邮件账户等等。它。如果仍然不够，请为已经这样做的公司解释诉讼和罚款的例子。

无论你做什么，都不要解释任何技术细节。只是显示后果。不要解释哈希，盐，或使用像“明文”这样的词。只是解释现在是这样，人们可以看到密码，并且很容易改变它，以便没有人能看到密码，但它们仍然可以工作。

如果你无法说服他们，请不要接受客户。您应该警告应用程序的用户他们的密码没有安全存储。