使用 AJAX 发送纯文本密码有多安全？答案

【问题标题】：How safe is it to send a plain text password using AJAX?使用 AJAX 发送纯文本密码有多安全？
【发布时间】：2009-07-17 19:08:46
【问题描述】：

也许标题措辞不当，但想不出更好的表达方式。

我目前正在开发一个登录系统（不是正式的，只是在试验）并计划使用 PHPLiveX（一个 AJAX 库）来实现某些功能。基本上，您创建了一些 PHP 函数，然后通过 JavaScript 调用这些函数。您可以将参数 (getElementById) 添加到传输到 PHP 函数的 JavaScript。

我真正想知道的是，仅从 JavaScript 调用函数而不首先加密密码，然后让 PHP 函数对其进行加密（在本例中为 SHA256）是否安全。通过AJAX传输的数据会被截获吗？如果有，这种可能性有多大？

【问题讨论】：

除了使用 SSL 之外，最好的保护方法是什么？如果可以在 JavaScript 中对密码进行哈希处理，这是一个合理的解决方案吗？
如果你在 JavaScript 中散列密码，任何嗅探流量的人仍然可以看到它（它只会被散列！）攻击者可以使用散列密码轻松重播此请求跨度>
而 SSL 会解决这个问题吗？
SSL 将加密整个 POST 请求（并就此进行回复）。所以是的，它会解决这个问题。
嗨，我这样做的原因是为了更好地理解它。我根本没有为任何严肃或正式的事情实施这个。

标签： php ajax security authentication login

【解决方案1】：

与浏览器发出的普通 HTTP POST 请求相比（如来自<form>）或多或少安全

此问题的“修复”与非 AJAX 请求的“修复”相同 - 使用 SSL。

【讨论】：

很好的答案，谢谢。那么没有与 AJAX 相关的安全漏洞吗？
或者挑战回复，看我的回答。
@briggins5 就像 Peter 所说，AJAX 只是不按顺序或“异步”发生的 HTTP POST 请求。所以，从某种意义上说，你是对的。但是，由于 AJAX 是异步的，客户端浏览器中的状态变化更难理解，因此更容易破坏安全性。

【解决方案2】：

正如其他人所提到的，这并不比从表单发送 HTTP 帖子更危险。事实上，这完全是一回事。

但如果 HTTPS 不是一个选项，您始终可以在未加密的连接上使用质询/响应方案。基本上它是这样工作的：

服务器具有用户密码的 SHA（或您喜欢的任何散列算法）散列。
客户有密码。
客户端请求（使用未加密的 AJAX）服务器发送质询（随机的字节字符串；字符可以。）
服务器创建一个质询和一个质询 ID，并在到期后保存。
客户端收到挑战和挑战 ID。
客户端使用 SHA 对密码进行哈希处理。
客户端对生成的哈希值进行哈希处理，并以某种方式附加质询。
客户端发送质询 ID（不是质询本身）和生成的第二个哈希值。
服务器使用 ID 查找质询（如果存在且未过期）。
服务器将质询附加到存储的密码哈希并使用与客户端相同的方案创建哈希。
服务器将其哈希值与客户端进行比较。如果相同，则用户已通过身份验证。

一旦你有了想法，设置起来其实很简单。 Wikipedia 有一些额外的信息。

编辑：我注意到我忘了提及，无论身份验证是否成功，您必须删除挑战，无论如何。让客户多次尝试一项挑战可能会导致安全问题。

【讨论】：

听起来是个好方法。与传统身份验证（仅比较用户名和密码）相比，我想了解一些人的意见，这有多安全？
与仅以纯文本形式发送用户名和密码相比，它的安全性如何？好吧，如果您将 0 的值附加到该方法，并且我的方法是一些 n > 0（为了论证，甚至说 0.0005），我的方法是 >1,000,000,000,000,000 倍更安全。
很久以前我问过同样的问题。这是另一个描述它的链接（带有一些额外的怪癖）：gamedev.net/community/forums/viewreply.asp?ID=3353014
破解这个比破解 SSL 要容易得多。如果你不加盐密码，你可以在几分钟内用一些下载的彩虹表破解它。如果你对密码进行加盐，攻击者仍然可以捕获散列密码并尝试猜测它——SHA1 非常快，现代计算机每秒可以尝试数百万个密码。（不要重新发明 SSL！）
@jrockway：首先，这不是重新发明 SSL。挑战/响应仅适用于确定两方何时知道相同的信息。其次，Salts 不是秘密，一种可以接受的用于防御彩虹表的加盐方法是：hash = SHA (SHA (password) . salt)。在此设置中，盐是挑战，其目的变为两倍哈希 = SHA (SHA (password) .challenge)。第三，我以 SHA1 为例。如果您需要额外的安全性，可以使用更大的方案。

【解决方案3】：

无论您是通过 AJAX 还是通过普通形式发送密码，它仍然是通过 HTTP POST（希望如此）请求发送的。因此，您不会添加或删除任何安全方面的内容。

防止有人截取您的密码的唯一方法是使用 SSL（通过或不通过 AJAX）。

【讨论】：

【解决方案4】：

这就像通过网络发送不受 SSL 保护的登录表单一样安全，就像几乎所有的论坛一样！

【讨论】：

【解决方案5】：

确保您的 AJAX 调用的目标是受信任的 HTTPS:// 页面，并且您已使其与任何其他发送与您的应用程序的其余部分相同的信息一样安全。大多数库/框架不会将您的 AJAX 调用限制为仅使用 HTTP://。

【讨论】：

【解决方案6】：

是的，它可以阅读。就像其他没有某种安全层的东西一样（参见 SSL）

要自己查看它，请在执行 AJAX 命令时运行 WireShark 之类的工具。

可能性有多大？不是很多，但用户的密码可能会以纯文本形式保存在某人的日志文件中。如果有人最终找到它，那可能是个坏消息。回到大学，我的网络课可以使用一些（半）高档路由器。我们有一些任务，我们在随机网站上注册帐户。当我们这样做时，我们注意到路由器的日志文件中有一些非常可怕的东西。这让我大开眼界，让我思考如何跟踪每一次通信并很可能记录在某处。

【讨论】：

【解决方案7】：

AJAX 调用只是普通的 HTTP 请求。

它的行为就像普通的 HTTP 请求一样，也有它的所有优点和缺点。这并不安全。

为了让您的 AJAX 调用安全，您可以尝试以下几种方法：

使用 SSL。 SSL 将加密您的用户和服务器之间的消息。 SSL 的缺点是您必须为有效的 SSL 证书支付额外费用。无效的 SSL 证书在可用时无法为用户提供同等级别的安全保证。
在发送前加密请求，客户端。例如：在通过网络发送之前对用户的密码进行哈希处理。大多数时候，无论如何您都不需要用户的纯文本密码。这在用户不允许客户端脚本运行时不可用。
除了 POST 比 GET 更安全的常见误导性信息之外，事实并非如此。两者都对攻击者开放。

【讨论】：

-1：误导性答案。 AJAX 执行与普通旧表单相同的请求。
我的回答中哪一部分说“AJAX 不会像普通的旧表单那样做同样的请求”？
@Adrian：实际上，正是缺失的信息让没有这些知识的人认为它在某种程度上有所不同。
他说的是“误导”，而不是“明显不正确”。我同意他的观点，尽管我不会为此而对你进行-1。我只是评论一下。
@Adrian - 你的#2 不起作用，因为任何可以嗅探流量的人都会看到散列密码并且可以轻松地重播它。散列的唯一好处是（如果正确加盐）它将很难获得预先散列的密码

【解决方案8】：

您以明文形式发送，因此任何嗅探/侦听/等客户端网络的人都可以轻松查看密码。 AJAX 调用只是一个普通的旧 HTTP 消息。如果您想看到这一点，请启动wireshark 的副本并自己提出请求。您将能够在 HTTP 数据包中看到密码。

【讨论】：

【解决方案9】：

如前所述，SSL 是这里的最佳解决方案。但是，您可以在客户端散列密码。如果你用谷歌搜索它，你会发现很多 md5 的 javascript 实现。

【讨论】：

【解决方案10】：

这不安全。不要发送未加密的密码。他们很可能会在某个时候被拦截，您将遇到重大问题。

这是一个video 捕获远程登录密码的示例。 Telnet 以纯文本形式发送，这很好地说明了如果您考虑这样做时遇到的主要问题。任何两位脚本小子都可以比你更快地获取纯文本密码，所以“天哪，我的数据库去哪儿了？”

【讨论】：

愿意提供任何支持您观点的事实吗？

【解决方案11】：

通过 AJAX 传输的纯文本密码与通过普通 HTTP 帖子传输的密码一样安全。也就是说AJAX使用HTTP，因此可以被拦截和嗅探。最好的办法是使用 HTTPS (SSL)。

为了进一步了解 AJAX 和安全性，我推荐以下阅读材料

【讨论】：

【解决方案12】：

该死的你们让我担心。 SSL 不能防止 arp 中毒 MITM 攻击。像你们一样崇拜 SSL 是致命的。您必须有一种方法在客户端进行加密之前加密密码，否则即使是新手黑客也可以截取明文密码

【讨论】：

我认为这更适合作为评论。

【解决方案13】：

在构建使用 Ajax 的应用程序时，还应该非常注意潜在的安全漏洞。

以下网站有一些关于 Ajax 和 XSS 或 XSRF 攻击的非常好的信息http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf

不要忘记，当您让 javascript 调用可以访问远程函数时，用户可以简单地猜测函数调用并对其进行修改以执行他/她的指令。

【讨论】：