公司未加密密码时该怎么办

背景

我被合同帮助一家公司维护他们的服务器。我从事一些较小的PHP项目，但也研究性能问题，最近还扫描了黑客日志。

这些家伙已经运行了一段时间的服务器，并且在最后一刻拥有所谓的遗留应用程序。它使用魔术引号，全局变量（允许$id被覆盖$_GET['id']），使用.htaccess作为它们在某些情况下的唯一安全性，您可以为其命名。安全和编程的噩梦。

过去，我们一直被黑客入侵，大多数情况下是通过SQL注入进行攻击的，这种注入会运行SLEEP(99999999)命令并充当DOS攻击。幸运的是，他们没有运行“小鲍比表”，

XKCD：http：//xkcd.com/327/

因此，我将他们易受攻击的SQL语句mysql_query()（不是mysqli）重新编写为PDO事务。我也分析查询为SLEEP和UNION，我们不使用，但注射有。到目前为止，一切都很好。

最新一期

最近，我们被告知，用户数据库中的记录正在发生变化，例如用户的电子邮件地址更改为垃圾邮件发送者的电子邮件地址。

我注意到他们的专栏没有last_modified专栏，所以我们甚至都不知道何时更改了它们，更不用说是谁了。我添加了该专栏，但这仅是第一步。

当我查看此表时，我发现密码没有被添加盐分甚至是散列，只是保存为纯文本。

客户沟通

作为承包商，我如何才能在整个情况中与他们接洽，而又不会像疯子一样挥舞手臂？有什么建议吗？我当时在想一种冷静的方法，

    问题＃1
        概要
        为什么这是一个问题
        如果不固定怎么办
        建议的修复

    问题＃2
        概要
        为什么这是一个问题
        如果不固定怎么办
        建议的修复
        

您建议的冷静方法是最好的。指出当暴露这些数据时，由于密码重用，您的大多数用户将很容易遭受身份盗用。这将是一个很好的时机，指出这是影响Target的同一问题（假设公司不是Target）。您的经理应该很乐意更改此设置。

关于数据的合法性，我认为用户名/密码与CC数据，个人信息等相同。尽管这可能取决于您为用户提供的信息。我不是律师，因此最好从您的启示中提出这些方面，并应带到您公司的法律部门确定合法性。

https://zh.wikipedia.org/wiki/Information_privacy_law

您也可以使用此XKCD来帮助您：

这实际上取决于您要尝试解决的受众。我曾在有严重安全问题的公司工作过，例如您所说的，但是直到我向他们展示之前，他们都拒绝听到它。

如果可行，一种方法是基本上将您打算做的事情汇总在一起，逐项列出这些黑客中可能已经发生的事情。如果您的受众不是技术人员，则可能需要指出这些妥协可能带来的业务成本。显然，被黑的帐户会降低系统的信誉和产品的客户价值。更不用说使用纯文本密码和用户电子邮件地址的受感染系统，可能会导致严重的连锁反应。

如果可能的话，您下一步应该做的就是证明这一点。如果您可以在测试环境中使该系统正常运行，请执行此操作。然后在他们面前展示从应用程序的客户端对系统可能产生的影响。即使是技术人员，这也已证明对我很有说服力（尽管在我看来，他们通常仍然不采取行动）。

当然，就像您说的那样，您需要解释是否应该采取什么措施以及对实现这一目标的估计。尽管有些地方根本不管用，但它将帮助他们证明成本的合理性。至少您可以清除自己的意识，并知道自己尝试过就继续前进。

如果您说过已与您签订维护服务器的合同，那么此合同肯定必须在工作描述中包括一些任务，例如确保操作系统，应用程序软件和所有数据的完整性，安全性和可用性？！如果甚至有模糊的暗示，合同期望（并让您负责）确保服务器安全，那么我不会浪费时间将业务案例放在一起，而要做的就是确保问题得到纠正（前后备份，保持代码更改的版本历史记录。

我不希望这样的改变会花费一个上午的时间，如果他们问您花了什么时间在工作，那么您可以保留一份日记来解释和证明您的行动。只要您在合同范围内工作，此处就不会有问题。有时，让所有安全专家在决策者面前疯狂会导致恐慌，或者在最坏的情况下，他们会为他们提供机会，说他们不在乎这些问题，所以不要解决它，同时，如果发生以下情况，您仍然要承担责任违反！也许这并不总是最友好的业务方法，但是我的职业道德不允许我将未经加密的密码留在我曾经负责的任何系统中。

从个人经验中，我往往会发现我开始为新雇主或新客户工作时，预先讨论方案和期望可以为您节省很多压力，例如：如果我发现任何可以解决的安全问题，您是否会满意？我可以继续完成这项工作，而不必每次都来找您，只是通知您有关可疑的违规/事件？他们几乎总是对此表示同意，因为从他们的角度来看，他们对担心安全性或计算机内容不感兴趣-这就是为什么他们雇用了您！也许这不能像您期望的那样回答问题，但我希望它能为您提供思考的机会。祝您一切顺利，并希望问题能得到纠正！

当然，如果更改客户的电子邮件地址已经发生，并且被认为是一个问题-那么更改密码的能力也是一个问题。

现在，如果您已经足够保护数据库，以防止将来再次发生这种情况，那么任何人都可以编辑用户密码的机会也得到了固定解决，您只需要考虑是否有人现在可以阅读密码。

当然，如果可以，或者（如果不太可能的话）您还没有完全保护数据库，那么应该确定要对密码进行加密-怎么做？只需将其与“已更新电子邮件地址”问题放在相同的上下文中即可。这是否需要更改应用程序以及这是否是“太难”的问题，这是与他们一起提出的另一问题。查看代码，看看对他们进行建议的修复之前，更改代码的成本是多少。