【问题标题】:Password hashing (non-SSL)密码散列(非 SSL)
【发布时间】:2011-03-28 12:57:08
【问题描述】:

在非ssl传输的情况下,密码如何从浏览器发送到服务器?

我想在发送之前使用 bcrypt 对密码+盐进行哈希处理....但是 bcrypt 算法似乎没有 javascript 实现...

md5、SHA-1 够用吗?

PS:我的网站不存储任何用户个人信息。我只是希望用户预期的密码不会被黑客入侵,因为用户可能在包含他/她个人信息的其他网站上使用相同的密码

【问题讨论】:

  • 满足您需求的唯一远程安全 JavaScript 实现是 (enanocms.org/News%3aArticle/2008/02/20/...)。它保护会话 ID 和密码。如果黑客可以劫持会话,单独保护密码是完全没有意义的。甚至作者都说你应该使用 HTTPs,我同意,javascript 永远无法阻止 HTTPs 阻止的所有传输层攻击。

标签: javascript security authentication encryption


【解决方案1】:

说实话,您可以在前端对其进行哈希处理,但这并不能解决您的根本问题。由于您要存储散列以供以后验证,因此黑客只需要知道散列值是什么。然后黑客可以将哈希值发送给您,您的系统会将其验证为正确的值。您实际上是将未加密的密码发送到系统。

要完全有效,传输需要通过 SSL 加密。

实际上,解决散列问题的简单方法是播放man in the middle attack。由于它没有使用 SSL,因此使用浏览器的人无法知道 HTML 内容不是来自您的服务器。攻击者可以简单地将他的代码放在客户端和服务器之间,并在 HTML 中放置额外的代码来记录密码。然后发布的信息会发送给攻击者;他或她需要什么(在这种情况下是密码),然后将信息转发到您的服务器。你和攻击者都不会知道你没有互相交流。

这就是为什么您必须从可验证的来源购买证书的原因。他们正在验证您正在与之通信的服务器就是他们所说的那个人。

相关:Poisoning the DNS

【讨论】:

  • +1 真正的 SSL 加密 + 明文传输密码。在后端散列。
  • 散列值总是不同的,这就是你加一点盐的原因。 SSL 不是唯一的出路。
  • @Ishtar 没用。如果您实际上要使用用户表中的哈希进行身份验证,则需要在进行哈希之前以某种方式将其发送到浏览器......这意味着现在您只是在实施挑战/响应身份验证非常糟糕(并且仍然容易受到重放攻击)。如果您不知道自己在做什么,这真的不是一个乱七八糟的地方。 :)
  • @Ishtar,这不是真的。散列值必须是可重现的,才能将其与存储的内容进行比较。问题来自散列值未加密发送的事实。我不需要密码进行身份验证,我需要在这种情况下我可以得到的散列值,因为它是未加密发送的。
  • @Ishtar 什么??不,这不是哈希的工作方式。添加盐是一种防止基于彩虹表的哈希破解攻击的方法。
【解决方案2】:

您的方法似乎很不安全。但是要解决您的问题...

  1. 与通过 SSL 发送的方式相同,只是未加密。
  2. 不,MD5 不够好,即使在 SSL 上也是如此。如果你真的担心安全性,那你为什么要选择一个破解的算法,可以是deciphered using a multitude of web services online(这一直是这里关于 SO 的一些激烈辩论的焦点)。
  3. 即使您在发送密码之前对密码进行哈希处理,您也是在执行此客户端。这意味着您的哈希和算法会公开并显示给每个最终用户。因此,一个成功的黑客现在可以确切地知道您是如何发送密码的。

最后,如果您想在从客户端传输到服务器期间保护您的站点/文本,只需从 GoDaddy 获得至少 20 美元的 SSL 证书。在存储到数据库之前在服务器端加密您的密码。

【讨论】:

  • 我相信我在开场白中说过。告诉我 SSL 和服务器端哈希有什么问题?
【解决方案3】:

或许你可以尝试实现APOP命令http://www.ietf.org/rfc/rfc1939.txt

【讨论】:

    【解决方案4】:

    根据您的操作,您可能可以将身份验证卸载到 openid。

    【讨论】:

    • 不管 JavaScript 的完整性如何,应该注意的是,您仍然可以通过此操作进行会话劫持。
    【解决方案5】:

    我始终建议人们尽可能使用 SSL,但为了完整起见,应该注意可以通过仔细实施 HMAC -- Hash-Based Message Authentication Code 在不使用 SSL 的情况下安全地执行身份验证。

    您必须确保使用带有 HMAC 的加密安全哈希算法(我建议使用 SHA-224 或更好的算法),并且您必须记住,尽管您可以在不泄露密钥/密码的情况下进行身份验证,但您的 数据仍然必须以明文形式传输,因此不能用作 SSL 的替代品,例如信用卡交易等。

    【讨论】:

    • @The Rook:您需要某种形式的单独安全(或足够安全)通道,我链接到的 Wikipedia 文章对此进行了解释。正如我所说,这需要仔细实施,而不是我推荐的行动方案。这不会使我的答案错。
    • @Nicholas Knight 可以进行 DH 密钥交换。但是,如果您只是泄露经过身份验证的会话 ID,那么如何传输密码并不重要。我的 -1 留在这个答案。
    • @The Rook:再一次,你表现得好像我的回答是对如何正确实施 HMAC 身份验证的全面描述。它不是。这只是一个指向正确方向的指针。正确的 HMAC 实现不会出现您认为的问题。特别是,正确使用 HMAC 没有任何正常意义上的“会话 ID”。
    • @Nicholas Knight 您的回答不会保护任何人,也绝不是 ssl 的替代品。此外,这是对 HMAC 的错误使用。
    • @The Rook:无论发送什么消息。例如“订单 X 数量的小部件运送到 1234 Some St.”。如果您不了解如何使用 HMAC 对 Web 交互进行身份验证,那么您就没有资格谈论安全问题,更不用说批评他人了。
    【解决方案6】:

    嗯,

    挑战响应协议可以在这里工作。

    客户端获取登录页面
    1) 开始会话
    2) 生成会话密钥
    3) 发送会话密钥作为哈希目标
    用户登录,按提交
    1) Javascript 任务 SHA-1 的会话密钥 + SHA-1 的密码,将结果写入密码字段
    2) Javascript 提交表单
    3) 服务器获取会话密钥的 SHA-1 + SHA-1 密码哈希并进行比较

    会话密钥可以防止窃听者重播流。服务器会记住它是什么。

    但是,密码的 SHA1 应该使用盐。简单地使用用户名可能足以防止预建的彩虹表工作。由于盐会在此协议中暴露出来,因此您无法完全击败彩虹表。

    编辑:回想起来,我没有说清楚一件事。我所说的会话 ID 不是 PHP 会话 ID。它是一个额外的 id,存储在会话变量中,并以表单的形式传递给客户端。它需要用于身份验证一次并从 PHP 会话变量后记中丢弃。尽管如此,嗅探器可以在那之后劫持会话。

    请记住,所有这些问题都是为了保护密码免受嗅探器的侵害。他自己的网站完全容易受到任何可以嗅探和劫持会话的人的攻击,他知道这一点。

    BIG FAT 警告:MITM 攻击者可以将 javascript 代码替换为其他操作,例如为他提供密码副本。只有 SSL 可以防止这种攻击。

    【讨论】:

    • @The Rock:我真的不在乎你的个人资料说什么——尽管正如你自己指出的那样,无论如何我不应该相信你说的话。我当然不会相信那些吹嘘自己在安全问题中获得最高票数但删除了他被否决的答案的人。不过,作为记录,我不认为你在撒谎,我认为你在 Web 应用程序和密码系统的设计方面缺乏经验。攻击设计糟糕的系统与创建好的系统不同。
    • @The Rook:你不会是第一个偶然发现以前未知漏洞的脚本小子,并且引用 The Register 并不能完全提高你的可信度。
    • @The Rook:让我直言不讳:我是对的,你错了,因为你不同意那个评估而试图命令我不要做某事不太可能让你得到希望-结果。
    • @The Rook:让我非常清楚地说明这一点:如果您对用于验证 Web 请求的适当 HMAC 解决方案的安全性的评估是准确的,那么加密签名的基本属性就会被破坏。他们不是,所以你错了。
    • @The Rook:这是我们试图避免的精确篡改。我们正在努力确保在不传输共享机密本身的情况下,请求来自授权用户。 HMAC 可用于提供该保证。我们在这里不是为了确保隐私,而只是为了完整性。
    猜你喜欢
    • 2011-02-18
    • 2015-08-13
    • 2012-05-30
    • 1970-01-01
    • 2011-06-23
    • 2018-01-20
    • 1970-01-01
    • 2011-04-06
    • 2011-05-10
    相关资源
    最近更新 更多