【问题标题】:Why should I care about hashing passwords anyway?我为什么要关心散列密码呢?
【发布时间】:2008-11-13 17:27:39
【问题描述】:

如果黑客可以访问我的数据库中的哈希值,那么他无论如何都可以访问数据库中的其余信息。那么他为什么还要费心尝试解密密码呢?我应该将密码存储在与我的其余数据不同的服务器上吗?这是我可以设想它有用的唯一场景。

【问题讨论】:

    标签: security encryption


    【解决方案1】:
    1. 有时黑客无法完全访问您的数据库。有时他们会发现一些 SQL 注入漏洞或其他人没有正确编码的弱点,所以他们一开始只能做一些简单的事情,比如一次打印一个数据库单元格。如果他们能突然打印出真正的密码,事情就会变得更糟。

    2. 会发生以下情况:备份磁带丢失、意外丢弃或被盗。已退役的系统未正确擦除。其他地方的漏洞会导致数据库意外暴露。如果黑客可以访问这样的快照,他可以了解很多关于您的系统的信息。但如果密码仍然经过哈希处理,他也不能使用系统进行恶意操作,例如以其他用户身份登录并开始更改内容。

    3. 我听说大多数黑客都是内部工作。即使您信任的人以其他人身份登录,也最好删除该功能。

    4. 这不仅仅是关于你。用户倾向于跨系统共享密码。也许有一天(上帝保佑)您有与密码无关的违规行为,但在此过程中,您的身份验证表将成为攻击者的目标之一。如果您以纯文本形式存储密码,那么您也只是在许多其他服务中泄露了用户帐户,而您的糟糕日子只会变得更糟。

    如果你认为这种事情不会发生,去和 reddit 的人谈谈。

    【讨论】:

    • 我只是喜欢在 o_0 一天的代表人数已经达到最高水平后,对一个问题获得 11 次以上的支持。
    • /> 从用户中删除 userid="Joel";
    • 这应该被接受的答案<_>
    【解决方案2】:
    1. 人们经常对其他网站上的不同账户使用相同的用户名/密码(包括,例如,在线访问银行账户)。

    2. 一旦您发现此黑客并保护了您的数据库,黑客仍然可以登录您的用户帐户。

    【讨论】:

      【解决方案3】:

      最佳安全实践建议:

      • 您应该为您拥有的每个帐户使用唯一的(用户 ID、密码)对。但是大多数人将一对资源用于许多资源(电子邮件、银行、)。攻击者可以从一个资源中窃取它们并使用它们来访问另一个资源。使用 salt 对密码进行散列(参见 http://en.wikipedia.org/wiki/Salt_(cryptography))可以防止此类攻击。

      • 您应该加密数据库中的所有敏感数据,而不仅仅是密码。您关于有人可能会窃取您的整个数据库(或您的服务器)的观点是完全正确的。

      • 您应该将您的 Web 服务器与您的数据库和任何其他宝贵资源分开,以隔离对您最不重要的资产的攻击。

      还有散列密码的商业原因。请记住,散列意味着您不会将用户密码存储在设备上的任何位置

      • 根据适用的法律,您可能要求在某些情况下这样做。

      • 如果您的数据被盗,您的曝光率会大大降低。

      • 社会工程 攻击让您更安全,在这种攻击中,攻击者冒充有效用户并诱使员工泄露密码。见http://en.wikipedia.org/wiki/Social_engineering_(security)

      【讨论】:

        【解决方案4】:

        我应该将密码存储在 与我的其他服务器不同的服务器 数据?

        这会增加您系统的复杂性,但如果您能做到这一点,那绝对是一种改进。

        请注意,使用 Kerberos、RADIUS 或 Windows 域身份验证等身份验证服务器会有效地将您的密码放在另一台服务器上。

        【讨论】:

          【解决方案5】:

          因为即使您可以访问数据,访问 APPLICATION 实际上更重要。例如,该应用程序使操作数据变得更加容易。

          对密码进行哈希处理可防止所有人意外暴露。

          例如,您很可能在多个网站上使用相同的密码。快速浏览一下 DB 不仅会影响您的应用程序,而且可能会影响其他几个应用程序。

          对密码进行哈希处理是一种很好、可靠的做法。

          【讨论】:

          • 我不同意。访问实时数据库要危险得多。至少通过应用程序,您仅限于其业务规则。例如,该应用程序可能不允许您删除表,并且您可以锁定受损的用户帐户。
          【解决方案6】:

          主要是因为把它做好几乎是微不足道的,而且收益可能非常高。

          【讨论】:

            【解决方案7】:

            有时,您不知道谁将成为系统管理员。您仍然希望保护您的用户免受他们的侵害。因此,通过散列密码和所有重要信息(例如信用卡),您使黑客或管理员变得更加困难。而且,我认为密码永远不应该按字面意思写。我的意思是,我使用密码已有 2 年了,但我从未见过它写下来。为什么我不认识的管理员应该看到我的密码?!

            【讨论】:

            • 托管就是一个很好的例子。这是您的服务器,但它位于其他人的数据中心,其他人可以物理访问该机器。
            【解决方案8】:

            使用散列密码可以防止攻击者登录您的应用,即使他们知道散列。您的登录页面要求输入原始密码,因此要使用它登录,他们必须反转哈希(计算冲突)。使用彩虹表,这对于 MD5 来说是相当微不足道的,例如,这就是加盐的地方。然后攻击者需要知道 1)你结合盐和密码的方式(那里没有太多的安全性),2)盐(这可能已经在数据库中)和 3)他们必须为密码和盐的每种组合计算该值。这不仅仅是计算常用密码的哈希值并寻找匹配项。

            【讨论】:

              【解决方案9】:

              当黑客访问您的数据库时,这并不意味着他可以访问程序代码,这些程序可以更改被黑客入侵的数据库边界之外的数据库,或者包括可以更改其他程序。

              现在我要问你一个问题:如果一个用户被黑了并且有人知道了他或她的密码,你如何明确这不是你的应用程序或安全问题?

              如果您没有存储密码,您就没有这种责任!

              【讨论】:

                【解决方案10】:

                如果应用程序要在大学显示成绩信息,那么访问密码将允许您获得该人的成绩。如果密码还允许您登录在线课程系统,那么您可以以该用户身份提交测试。

                如果数据更加敏感,例如信用卡号码或健康记录,您可能会面临诉讼。

                更有可能的是,更敏感的信息可能位于更安全的系统上,位于更强大的防火墙后面,因此他们可能通过入侵身份验证数据库发现了弱点。

                通过对密码进行哈希处理,那些有权访问身份验证数据库的人无法看到密码,因此以不同的用户身份登录到非常敏感的系统。

                【讨论】:

                  【解决方案11】:

                  整个LinkedIn "scandal" 都是关于泄露的散列密码。

                  在我看来,安全性只是让数据检索不方便

                  不方便在理想情况下,我们的意思是您需要数百万年的计算时间才能访问(即尝试猜测密码的单个 CPU 将承担百万年的规模)。

                  如果您以明文形式存储密码,则总共需要 0 个计算年才能访问。 LinkedIn 的丑闻看起来会更糟。您所要做的就是SELECT * FROM USERS(通过注入或内部人员)。

                  人们经常重复使用密码,因此如果人们知道了您的密码,这意味着他们可以访问整个世界的数据(例如,不仅仅是他们的 LinkedIn)。所以它变成了一个非常个人的风险。作为网站管理员,至少散列密码是粗鲁:您对用户采取基本步骤的尊重并不多试图保护他们的信息。

                  即使散列密码可以被破解,您也至少要采取最低限度的措施来保护您的用户。

                  【讨论】:

                    【解决方案12】:

                    如果他可以解密密码,他可能也可以访问您用户在其他网站上的帐户(因为无论我们告诉人们不要重复使用密码多少次,他们都会这样做)。存储明文密码是泄露所有用户的 PayPal、eBay 和 Amazon 帐户的好方法。

                    【讨论】:

                      猜你喜欢
                      • 1970-01-01
                      • 2023-03-18
                      • 2012-12-19
                      • 1970-01-01
                      • 1970-01-01
                      • 2014-01-05
                      • 1970-01-01
                      • 1970-01-01
                      • 2021-08-02
                      相关资源
                      最近更新 更多