代码之家  ›  专栏  ›  技术社区  ›  Mia Clarke

GWT/javascript客户端密码加密

  •  15
  • Mia Clarke  · 技术社区  · 15 年前

    我正在我的GWT应用程序中实现授权,目前它是以以下方式完成的:

    1. 用户通过将其凭证放在表单中进行注册,然后我将它们以明文形式发送到服务器。
    2. 服务器代码使用bcrypt散列接收到的密码,并将散列放到数据库中。
    3. 当用户登录时,他的密码会以明文形式发送到服务器,服务器会根据存储的哈希值检查密码。

    现在。困扰我的是我将密码发送到服务器的事实很清楚,我一直在想,如果我使用的应用程序将密码与我的(用于所有类型的)密码一起发送,我将不会非常高兴,但在客户端上对其进行加密并不能真正为我赢得任何东西,因为攻击者可以使用像清除密码一样删除密码。

    我一直 googling 为了这个,似乎互联网在这方面是相当一致的-显然没有什么可以从客户端密码加密获得的。 This , this this 这些只是我经过的讨论和页面的几个例子,但还有很多很多,更多的,都说同样的话。

    考虑到这一切,这个问题似乎有点不必要,但我希望某个地方,某个人,能给我另一个答案。

    我能做什么, 如果此时SSL不是一个选项 为了让我放心?有什么要做的吗,或者实现某种客户机加密服务器解密方案只是一个耗时的、虚弱的、死气沉沉的过程吗?

    3 回复  |  直到 12 年前
        1
  •  9
  •   Chris Lercher    15 年前

    对于登录,即使在此时,SSL也应该是您的选择。如果只是为了登录,您不需要昂贵的SSL服务器场,但至少您要保护(用于所有类型)密码,即使很明显,其余的通信并不安全。 [*] . 这可能意味着,您只需要为一个登录服务器购买一个证书,这可以再次为您节省很多钱,具体取决于证书供应商。

    对于GWT,如果您不能对所有通信进行加密,那么由于相同的源站策略限制,您必须将登录放在单独的页面上。

    如果这仍然不是一个选项,您可以考虑通过 OpenID ,就像stackoverflow一样。

    不能有 任何 在不安全的媒体上进行安全通信 一些 预先共享的秘密——通常由安装在浏览器中的根证书提供(顺便说一句,浏览器甚至整个操作系统通常都是通过HTTP下载的,这很有趣/可怕)。其他系统,例如PGP,依赖于先前建立的对 "Web Of Trust" 但这只是另一种形式的预先共享的秘密。这是不可能的。

    [*]对所有内容使用SSL——不幸的是——会带来额外的实际问题:1)页面加载速度要慢得多,尤其是在页面上有许多元素的情况下。这是由于SSL引起的往返以及由此产生的延迟,即使是最快的SSL场,也无法应对这些延迟。该问题得到了缓解,但不能通过保持连接完全消除。2)如果您的页面包含来自外部非https站点的元素(例如用户插入的图像),许多浏览器将显示警告-这些警告对于真正的安全问题非常模糊,因此对于安全站点通常是不可接受的。

    一些额外的想法(不是建议)

    让我们假设一下最坏的情况,也就是说,您根本不能使用SSL。在这种情况下,也许令人惊讶的是,在传输密码之前对其进行哈希(使用salt),实际上可能比什么都不做要好一些。原因是:它不能打败Mallory(在密码学中,一个可以操纵通信的人),但至少它不会让Eve(一个只能听的人)读取明文密码。如果我们假设Eves比Mallorys更常见,这可能是值得的。但是请注意,在这种情况下,您应该散列密码 再一次 (使用不同的salt),然后将其与数据库值进行比较。

        2
  •  5
  •   Igor Klimer    15 年前

    如果SSL不是一个选项,那么您显然对安全性不够关心;)

    但是说真的-就像你提到的,客户端密码加密不是一个好主意。事实上,这是一个非常糟糕的。你 不能 相信jack的客户端-如果攻击者设法更改了JS代码(通过XSS或在它通过网络发送时),使您的MD5/whatever hash函数只通过明文传递,该怎么办?更不用说,你应该使用一种好的、强的、咸的加密方法,比如bcrypt——这种方法在客户机上速度很慢,就像前面提到的那样,并不能很好地增加应用程序的安全性。

    您可以尝试绕过其中的一些问题:通过一些安全的方法发送哈希库(如果这在第一时间是可能的,那么我们现在就不必麻烦所有这些问题了,是吗?)通过在服务器和客户机之间共享一个公共秘密并将其用于加密… 但底线是:尽可能使用https (在GWT中,很难混合使用HTTPS和HTTP) 正当的 (如果用户愚蠢到使用相同的密码来访问与安全无关的应用程序和他的银行账户,那么他/她很可能在其他一些网站上使用相同的密码,任何一个都可能导致密码被劫持)。其他方法只会让您认为您的应用程序比它更安全,并使您不那么警惕。

        3
  •  1
  •   CodesInChaos    15 年前

    考虑使用 SRP .

    但是,如果中间人向你发送邪恶的javascript,而Simpy向攻击者服务器发送密码副本,这仍然没有帮助。