代码之家  ›  专栏  ›  技术社区  ›  bastianneu

根据客户需求,在数据库中以纯文本形式存储密码

  •  12
  • bastianneu  · 技术社区  · 15 年前

    我想称之为“在数据库中以纯文本形式存储密码”是一个糟糕的做法…但是我们的客户在他的应用程序中做了这个。他们要我更新那个申请。

    我的观点是:我想改变这个……但由于它不是我们客户的需要,所以还不清楚。

    你如何处理安全问题?在我看来,很难向客户解释这些问题。

    11 回复  |  直到 15 年前
        1
  •  7
  •   caf    15 年前

    写一封简短、清晰、不含行话的正式信函,说明您的担忧,并得出结论,在您的专业意见中,应该予以纠正。向客户中相当高的人说明。

    如果他们选择无视你的建议,那是他们的特权。

    (你自己也要留一份这封信。)

        2
  •  11
  •   Rik elirevach    15 年前

    我认为“坏习惯”是轻描淡写的。“不负责任”可能更准确。

    如果值得用密码来保护它,那就值得正确地进行保护。以纯文本格式存储密码是一个令人尴尬的安全漏洞,等待发生。

    如果“安全”在你的客户想要的任何地方(我想是的,因为有密码),他们就暗中要求一个体面的安全系统,其中包括正确处理密码。他们可能不会要求“安全地存储密码”(哈希和盐),因为他们不是专家;这就是他们雇佣你的原因。

        3
  •  4
  •   tschaible    15 年前

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

        4
  •  4
  •   Bittarman    15 年前

    最好的理由,永远不要保持密码在纯文本实际上是合法的。

    有一些法律,如英国的数据保护法,规定必须采取合理的措施确保敏感数据的安全。以纯文本形式存储密码显然会违反这一点,并且在违反安全性的情况下,可能会使您拥有的任何赔偿保险失效。如果你不采取这个简单的措施,这将使你面临一个巨大的责任诉讼。

    当涉及到商务人士时,你总是要谈论他们的口袋,并指出一个小时的工作来散列密码,并更改登录将花费他们一小部分,与潜在的成本相比,如果发生了严重的错误。

    同样值得注意的是,如果有人设计了这样一个根本上有缺陷的系统,那么很可能存在这样一个错误,它会暴露出这样的敏感数据 指数地 较高的。

    除此之外,正如其他人所说,现场演示是好的。从数据库中随机抽取一个工作人员的密码,然后在他们的其他系统中进行尝试,在进入之前您不必尝试太多密码。

        5
  •  3
  •   Community Dunja Lalic    7 年前

    不要以纯文本形式存储密码。

    我建议阅读这些问题:

    如果您的客户对细节不感兴趣,只需实现它。(还提供正确的密码恢复过程)。作为一名程序员,这对你来说并不是什么大不了的事情,但确实可以提高产品的安全性和质量。

    如果他想知道你打算改变什么-向他解释。告诉他安全问题,他会理解的。另外,一个活生生的例子确实有助于打开客户的眼睛:简单地从他们的旧系统中检索他的密码,并向他展示这对每个人都是多么容易。

    我一直都是这样做的:如果我觉得在我的产品中有一个安全功能很重要的话——我总是把它包括在内。它为您的产品质量增加了一个巨大的优势,并给您许多“哇,你想的每件事”的时刻。

        6
  •  2
  •   PowerUser    15 年前

    巴斯坦努,你知道英语中“cover your a**”这个词吗?想象一下这个场景:

    1. 你担心他们不关心安全,他们也不想听你的消息。不管怎样,你告诉他们,他们拒绝任何改变。
    2. 他们被黑客攻击了。
    3. 他们问你为什么不早点说。

    我建议你事先把你的顾虑说出来。并保存证据(签名信等)。

        7
  •  1
  •   Patrick Desjardins    15 年前

    您应该简单地向客户解释,如果有人恶意访问数据库,那么登录是不安全的。如果应用程序在公司内部,也许不值得更改它。你必须分析它是否真的是一个价值,你只能通过与客户交谈来了解它。也许这些数据不是很机密,也不是拥有大量安全性的优先事项。所有这些都取决于软件目标、数据库在哪里以及客户希望其数据安全。

        8
  •  1
  •   dominic    15 年前

    我会解释他们所做的是不好的实践,并问他们是否希望你改变它。我会建议你不要在许可证之外做任何事情,不要在没有咨询他们的情况下做你被要求做的事情。

        9
  •  0
  •   Donato Azevedo    15 年前

    从严格的专业角度来看,你必须问自己,是否会在以后成为一个问题(如果盗贼从数据库偷取通行证,你是否有可能被要求的支持合同?)

    就我个人而言 认为很难向某人解释为什么存储未加密的密码是不安全的,但是,正如Daok指出的,您真的不必担心在不保存私人秘密魔法数据的系统上传递。

    如今,为了实现这一目的,使用加密似乎非常容易,这取决于您使用的技术,这可能意味着在编码和完成这项工作的时间上只需付出一点点努力。

    干杯!

        10
  •  0
  •   Unsliced    15 年前

    演示和解释是最有用的,但是当您说要“更新”应用程序时,您是从文档、功能或技术规范开始工作的吗?

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

    最终,它 对客户的需求,他们只是还没有意识到。

        11
  •  0
  •   Brienne Schroth    15 年前

    在这种情况下,你必须恰当地表达事情。明文密码并不是你所说的“坏习惯”。这是你说的破碎的东西,根本做不到的东西。您必须使您的合同取决于他们的密码存储,这不是可选的。这并不是说你不能友好地讨论为什么不能这样做,但你必须明确表示,不管怎样,你都不会这样做。

    然后问题就变成了如何说服业务人员它不是一个有效的解决方案。这也应该相当容易。找到决策者,把他们带到一台打开数据库查询浏览器的机器上。输入查询“从username='decision-makers-username'的凭证中选择密码”,然后让决策者执行(礼貌一点,不要像他们那样看屏幕)解释任何具有数据库访问权限的员工都可以执行此操作。一般来说,我认为这会起到一定的作用,但是如果你需要做进一步令人信服的解释,那就是大部分用户在不同的应用程序之间共享密码,并且任何员工都可以使用密码破解银行账户、电子邮件账户等。如果这还不够的话,解释一下为那些已经这样做的公司提起诉讼和罚款的例子。

    无论你做什么,都不要解释其中的技术细节。只需说明后果。不要解释哈希、盐或使用“明文”之类的词。只要解释一下,就是现在,人们可以看到密码,并且很容易更改它,这样就没有人可以看到密码,但是他们仍然可以工作。

    如果你不能说服他们,就不要带走客户。您可能应该警告应用程序的用户,他们的密码没有安全存储。