|
1
9
对于登录,即使在此时,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
如果SSL不是一个选项,那么您显然对安全性不够关心;) 但是说真的-就像你提到的,客户端密码加密不是一个好主意。事实上,这是一个非常糟糕的。你 不能 相信jack的客户端-如果攻击者设法更改了JS代码(通过XSS或在它通过网络发送时),使您的MD5/whatever hash函数只通过明文传递,该怎么办?更不用说,你应该使用一种好的、强的、咸的加密方法,比如bcrypt——这种方法在客户机上速度很慢,就像前面提到的那样,并不能很好地增加应用程序的安全性。 您可以尝试绕过其中的一些问题:通过一些安全的方法发送哈希库(如果这在第一时间是可能的,那么我们现在就不必麻烦所有这些问题了,是吗?)通过在服务器和客户机之间共享一个公共秘密并将其用于加密… 但底线是:尽可能使用https (在GWT中,很难混合使用HTTPS和HTTP) 和 正当的 (如果用户愚蠢到使用相同的密码来访问与安全无关的应用程序和他的银行账户,那么他/她很可能在其他一些网站上使用相同的密码,任何一个都可能导致密码被劫持)。其他方法只会让您认为您的应用程序比它更安全,并使您不那么警惕。 |
|
|
3
1
考虑使用 SRP . 但是,如果中间人向你发送邪恶的javascript,而Simpy向攻击者服务器发送密码副本,这仍然没有帮助。 |