对于 web 应用程序,当 HTTPS 不可用作为安全措施时,是否仍然可以使登录有点安全?例如:
- 令牌化登录,使重复攻击变得困难?
- 以某种方式加密从 HTML 密码字段发送的密码?
特别是我使用 CakePHP 和 AJAX POST 调用来触发身份验证(包括提供的用户名和密码)。
更新问题:
- HTTPS 不可用。时期。如果您不喜欢这种情况,请将其视为理论问题。
- 没有明确的要求,您拥有现实生活中提供的任何 HTTP、PHP 和浏览器(cookie、JavaScript 等)(没有神奇的 RSA 二进制文件、PGP 插件)。
- 问题是,什么是最好的,你可以从 这种 情况中看出,这比发送密码明文更好。了解每个此类解决方案的缺点是一个加号。
- 欢迎任何比普通密码更好的改进。我们的目标不是 100% l33tG0Dhx0r-prof 解决方案。难以破解总比破解复杂要好,后者比简单的嗅探密码要好。
原文由 sibidiba 发布,翻译遵循 CC BY-SA 4.0 许可协议
重新发明轮子是一种糟糕的工程实践。这样做的工程师正在成为“ 这里没有发明”偏见的受害者,当它是一个安全关键系统时,这可能会造成很大的损害。
HTTPS 背后的 SSL/TLS 对于维护网站和浏览器之间的安全连接 绝对至关重要。 公共 wifi 网络将用户置于危险之中,如果使用得当, HTTPS 是唯一 可以保护用户帐户免受 此漏洞影响 的工具。
如果有两个客户端需要安全的端到端 (e2e) 加密,则可以使用开源和经过审查的 信号协议,该协议已在 github 上获得多个开源端口,并被 WhatsApp 等流行应用程序广泛采用。没有必要自己酿造,这些协议运作良好是有原因的。
如果您的主机不支持 HTTPS,则可以使用 Cloudflare Universal SSL 等服务来确保所有浏览器都使用 HTTPS 连接到您的站点, _即使您的服务器不支持 SSL/TLS 也是如此_。 Cloudflare 与您的网站之间的连接仍将不受保护,但此 Cloudflare 服务旨在保护用户免受公共 wifi 网络上的威胁。从渗透测试人员的角度来看,不提供 HTTPS 是非常值得怀疑的,如果您在传输流量时不提供基本的安全要求,那么您还缺少哪些其他安全要求?可以使用 Let’s Encrypt 或 Start SSL 免费获得 HTTPS 证书,没有不支持 HTTPS 的正当理由。
HTTPS 非常重要,因为它不仅仅是“加密密码”。另一个重要的作用是它应该防止用户登录到冒充真实服务器的恶意服务器。单独使用系统来保护密码仍然违反 OWASP A9 - 传输层保护不足,因为您仍然会以纯文本形式传输会话凭据,而这正是攻击者所需要的 ( Firesheep )。
基于 JavaScript 的密码学不能用于构建安全传输层。
“令牌化登录”:如果攻击者正在嗅探流量,他们将拥有纯文本用户名/密码,然后他们可以使用这些新凭据登录。 (重播攻击)
“以某种方式加密传输的密码”:在用户登录后,攻击者可以嗅探流量以获取有效的 会话 ID (cookie),然后使用它而不是登录。如果整个会话都受到 SSL/TLS 的保护,那么这不是问题。
还有其他更复杂的攻击会影响此系统和我们当前的 SSL 基础设施。 SSLStrip 攻击更详细。我强烈推荐 观看 Moxie Marlinspike 的 Blackhat 2009 演讲,它导致了 HTTP-Strict-Transport-Security 标准。