没有HTTPS的登录，如何安全？

Question

对于when应用程序，当HTTPS不能作为一种安全措施时，还有可能使登录变得安全吗？例如：

HTML

• 令牌化登录，以进行重复攻击difficult?

• Somehow加密从密码字段发送的密码-

特别是，我使用CakePHP和一个AJAX POST调用来触发身份验证(包括提供的用户名和密码)。

问题的最新进展：

• HTTPS不可用。句号。如果你不喜欢这种情况，考虑一下理论上的question.
• There没有明确的要求，你有任何HTTP，PHP和一个浏览器(cookies，JavaScript等)。在现实生活中提供(没有魔法的RSA二进制文件，PGP plugins).
• Question是，什么是最好的，你可以使这种情况，那比发送明文密码要好。了解每种解决方案的缺点会更好。
• 欢迎任何比普通密码更好的改进。我们的目标不是100%的l33tG0Dhx0r-proff解决方案。难破解比复杂破解要好，比微不足道的嗅探泄露密码要好。

Answer 1

在维护网站和浏览器之间的安全连接方面，HTTPS是绝对重要的。如果使用得当， Public wifi networks put users at risk是唯一可以保护用户帐户免受this vulnerability攻击的工具。

如果您的主机不支持HTTPS，那么可以使用像Cloudflare Universal SSL这样的服务来确保所有浏览器都使用HTTPS连接到您的站点，即使您的服务器不支持SSL/TLS。Cloudflare和您的网站之间的连接仍将不受保护，但此Cloudflare服务旨在保护用户免受公共wifi网络上的威胁。从渗透测试人员的角度来看，不提供HTTPS是非常可疑的，如果您在传输流量时没有提供基本的安全需求，那么您还缺少哪些其他安全需求？HTTPS证书可以使用Let's Encrypt或Start SSL免费获取，没有合法的理由不支持HTTPS。

HTTPS至关重要，因为它不仅仅是“加密密码”。另一个重要的作用是，它应该防止用户登录到模拟真实服务器的恶意服务器。使用系统单独保护密码仍然违反了OWASP A9 - Insufficient Transport Layer Protection，因为您仍然需要以纯文本传输会话凭证，而这正是攻击者所需要的(Firesheep)。

1. JavaScript-based cryptography cannot be used to construct a secure transport layer.
2. "Tokenize登录“：如果攻击者正在嗅探流量，他们将拥有纯文本用户名/密码，然后他们就可以使用这些新凭据登录。(Replay attack)
3. "Somehow encrypt attack)
4. “Somehow transmitted password"：人登录后，攻击者可以嗅探流量以获得有效的会话id cookie()，然后直接使用它而不是登录。如果整个会话都使用SSL/TLS进行保护，那么这不是问题。

还有其他更复杂的攻击同时影响这个系统和我们当前的SSL基础设施。SSLStrip攻击涉及到更多细节。我强烈推荐通向HTTP-Strict-Transport-Security standard的watching Moxie Marlinspike's Blackhat 2009 talk。

Answer 2

由于您不能在web服务器上执行SSL，而且您也不是安全专家，因此请查找可利用的现有安全身份验证服务，并让它们为您处理SSL和处理凭据的复杂性。

特别是，我建议您使用免费的第三方身份验证服务，例如OpenID。他们有用于PHP的库，包括一个用于CakePHP的库。

编辑：(关于风险)

虽然使用第三方安全身份验证服务(使用HTTPS本身)可以在不使用HTTPS (在您的服务器上)的情况下自行进行身份验证来缓解问题，但它并不能完全消除攻击的可能性。

最常见的两种攻击是重放攻击和会话劫持，攻击者可以稍后重用真正的登录会话令牌，或使用有效的会话令牌来达到自己的恶意目的。

通过使会话令牌期满，并且优选地通过使用nonce来防止会话重放并降低会话劫持的风险，可以减轻重放攻击。对于现时值，如果成功劫持，合法会话将生成错误，因为现时值已过期(已被使用)，因此其自己的会话不再有效。

如果您无法使用HTTPS对传入和传出服务器的会话令牌进行加密，则无法完全防止会话劫持或中间人攻击等主动攻击。在某些情况下，这可能是可以接受的，例如非商业用途的用户基数较小的网站。

Answer 3

简而言之，如果没有SSL端到端加密，就不可能安全地进行加密……

其中一个主要原因是你不能在浏览器中进行安全加密。参见this reference - Javascript Cryptography Considered Harmful。

此外，您无法确定凭据的来源确实是您正在与之交谈的人。这意味着没有SSL绝对无法确保不存在Man-In-The-Middle Attack。

所以不，你不能这么做。

此外，甚至不要尝试。获取SSL。您可以免费获得证书。主机通常会给你一个专用IP，每月几个$$$。如果您真的关心安全性，那么无论如何都要使用至少一个具有专用IP地址的VM。

即使尝试这样做，充其量也是Security Through Obscurity，而在最坏的情况下，什么也不是。SSL是一个已经解决的问题。为什么不使用这个解决方案呢？安全性不是可以猜测的东西。使用适当的技术。不要试图创造你自己的东西。它不会工作的..。