没有HTTPS登录,如何安全？

Question

没有HTTPS登录,如何安全？

sib*_*iba 75 php security encryption ajax cryptography

对于Web应用程序,当HTTPS不可用作安全措施时,是否仍然可以使登录有点安全？例如:

Tokenize登录,难以重复攻击？
以某种方式加密从HTML密码字段发送的密码？

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

问题更新:

HTTPS不可用.期.如果您不喜欢这种情况,请将其视为一个理论问题.
没有明确的要求,你有任何HTTP,PHP和浏览器(cookies,JavaScript等)在现实生活中提供(没有神奇的RSA二进制文件,PGP插件).
问题是,什么是最好的,你可以摆脱这种情况,这比发送密码明文更好.了解每种此类解决方案的缺点是有利的.
我们欢迎任何比普通密码更好的改进.我们的目标不是100%l33tG0Dhx0r-proff解决方案.难以破解比破解复杂更好,这比揭露密码的琐碎嗅探更好.

Answer 1

roo*_*ook 75

HTTPS 对于维护网站和浏览器之间的安全连接至关重要.公共wifi网络使用户面临风险,如果使用正确,HTTPS是唯一可以保护用户帐户免受此漏洞攻击的工具.

如果您的主机不支持HTTPS,则可以使用Cloudflare Universal SSL等服务来确保所有浏览器都使用HTTPS连接到您的站点,即使您的服务器不支持SSL/TLS也是如此.Cloudflare与您的网站之间的连接仍然不受保护,但此Cloudflare服务旨在保护用户免受公共wifi网络上的威胁.从渗透测试人员的角度来看,不提供HTTPS是非常可疑的,如果您没有提供交付流量的基本安全要求,那么您还缺少哪些其他安全要求？可以使用Let的加密或启动SSL免费获取HTTPS证书,没有合法的理由不支持HTTPS.

HTTPS至关重要,因为它不仅仅是"加密密码".另一个重要的角色是它应该阻止用户登录冒充真实服务器的恶意服务器.使用系统单独保护密码仍然违反了OWASP A9 - 传输层保护不足,因为您仍然会以纯文本形式发送会话凭据,这是攻击者的全部需求(Firesheep).

基于JavaScript的加密不能用于构建安全传输层.
"Tokenize登录":如果攻击者正在嗅探流量,他们将拥有纯文本用户名/密码,然后他们就可以使用这些新凭据登录.(重播攻击)
"以某种方式加密传输的密码":此人登录后,攻击者可以嗅探流量以获取有效的会话ID (cookie),然后只使用此而不是登录.如果整个会话受SSL/TLS保护,那么这不是问题.

还有其他更复杂的攻击会影响此系统和我们当前的SSL基础架构.该SSLStrip攻击进入更多的细节.我强烈建议观看Moxie Marlinspike的Blackhat 2009演讲,该演讲导致HTTP-Strict-Transport-Security标准.

HTTPS不是******.大多数时候存在的问题无法通过要求将情况变为问题不会退出的问题来解决.假设在飞机失事后你被困在南极./幸存者:我们如何摆脱这种局面？没有移动网络覆盖来呼叫帮助./你:我们必须打电话求助!/幸存者:这个大陆没有网络覆盖./您:网络覆盖应始终可用. (46认同)
@sibidiba:重点是没有SSL,你*不能*使其安全.是的,您链接的方案"比明文密码更好".但它仍然没有"有点安全".除了改变场景之外,有时问题不是解决问题的好方法.如果您需要安全性,您的托管选择(或任何限制)是错误的. (9认同)
鲁克已经列出了许多关于你将要自己射击的方法的警告(在这里特别糟糕).我唯一的其他建议是查看摘要身份验证,这不是特别膨胀.它仍然容易受到MITM的影响,因为没有SSL登录页面,我甚至不知道登录提示的HTML是否来自你,所以我可以关闭我的DA.基本上你是在开玩笑密码系统.我不是说那是卑鄙的,也不是说你的.弄清楚如何打破"无SSL"问题,或者祈祷没有人对您的网站感兴趣. (6认同)
我(有点)意识到S在HTTPS中提供了什么.但在这种情况下,HTTPS不可用*.我的问题仍然是开放的,什么是最好的,什么是值得做的,什么时候不可用？ (5认同)
@sibidiba:你一定错过了我说"是的,它更好"的部分.这并不意味着你会称WEP为"安全",因为事实并非如此.是的,这是一个语义问题,但是你是否称之为"安全"是一个重要的区别. (3认同)
@Andrew:因为WEP加密容易破解,所以当只有WEP可用时,你根本不使用*加密？Crackable并不意味着你瞄准的攻击者也在这个级别上. (2认同)
@ESL你的帖子里没有"安全"或"解决方案" (2认同)

Answer 2

mct*_*ylr 16

由于您无法在Web服务器上执行SSL,并且您不是安全专家,因此请查找可以使用的现有安全身份验证服务,并让他们同时处理SSL和处理凭据的复杂性.

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

编辑:(关于风险)

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

最常见的两种攻击是重放攻击和会话劫持,攻击者可以在以后重新使用真正的登录会话令牌,或者为自己的恶意目的使用有效的会话令牌.

通过使会话令牌到期可以减轻重放攻击,并且优选地通过使用随机数来防止会话重放并且降低会话劫持的风险.对于nonce,合法会话在成功被劫持时会生成错误,因为nonce已过期(已使用),因此他们自己的会话不再有效.

如果在传输到服务器和从服务器传输会话令牌时无法使用HTTPS加密会话令牌,则无法完全阻止会话劫持或中间人攻击等主动攻击.在某些情况下这可能是可以接受的,例如用于非商业用途的用户群较小的网站.

这是一个非常糟糕的主意.问题是认证是您最不担心的问题.您需要保护整个会话.系统中最薄弱的部分是整个系统的优势.既然你提出了OpenID,[关于破碎的StackExchange auth的这篇文章是相关的](http://www.troyhunt.com/2012/08/is-stack-overflow-secure-kind-of.html).. (7认同)
@ircmaxell除了您引用的文章之外,未能澄清他的演示并未确定可能已经到位的服务器端会话管理的弱点的潜在解决方案,其中会话密钥为IP地址,也许是[nonce](http://en.wikipedia.org/wiki/Cryptographic_nonce)或者盐,并且有一个到期时间.即攻击者需要主动攻击进行IP欺骗,而不是仅仅被动地侦听(嗅探)TCP/IP或WiFi流量,而合法用户则主动登录. (2认同)
_需要保护整个会话_:这可以回到这样一个事实,即您需要对**特定**情况进行风险评估,并对攻击与安全的风险/回报进行权衡.如果TLS/SSL是不可用的,那么任何溶液将受到缺乏保密(或在[CIA] availability_的_excess(http://it.med.miami.edu/x904.xml)意义上)的,但这并不一定意味着完整性,身份验证或[不可否认](http://en.wikipedia.org/wiki/Non-repudiation)完全不可能,具体取决于所需的置信水平. (2认同)

Answer 3

irc*_*ell 15

简短的回答是,没有SSL端点到端点加密,就不可能安全地进行...

其中一个主要原因是您无法在浏览器中执行安全加密.请参阅此参考 - Javascript Cryptography Considered Harmful.

此外,您无法确定凭据的来源确实是您正在与之交谈的人.这意味着没有SSL就绝对没有办法确保没有中间人攻击.

所以不,你不能这样做.

此外,甚至不尝试.获取SSL.你可以获得免费证书.主持人通常会为您提供每月几$$$的专用IP.如果您真的关心安全性,那么您至少会使用具有专用IP地址的VM.

甚至尝试这种情况最好是安全通过晦涩,最糟糕的是没有.SSL是一个已解决的问题.为什么不使用该解决方案.安全性无法猜测.使用适当的技术.不要试图发明自己的.它不会起作用......

我想补充一点：如果有人在阅读本文时认为他们找到了一种开发比 TLS 更好的安全协议的方法，他们应该将其发送给 IETF 以考虑制定新的互联网标准。:) (2认同)

Answer 4

Jus*_*ier 13

正如您的建议,您可以在每次创建页面时生成唯一标记.需要使用表单数据发送相同的令牌,并且无法重复使用.如果您可以依赖用户启用它,您还可以使用JavaScript对其进行哈希,从而保护密码的安全.

然而,该方案仍然不安全.攻击者仍然可以看到一切都在线上.他们可以拦截令牌并在用户发送之前向您发送回复.或者他们可能只是等待某人登录,窃取该人的凭据(因为他们通过网络发送),并稍后发出他们自己的登录请求.

底线 - 您需要使用HTTPS来保证网站的安全.

Answer 5

SLa*_*aks 6

您可以使用Javascript加密密码并在服务器上解密.

我建议在服务器上生成一个RSA密钥对,将公钥和定时盐一起发送到浏览器,然后使用Javascript中的公钥加密密码,结合盐.

你可以找到在Javascript中的RSA实现这里

您应该在身份验证Cookie中包含IP地址和整个X- FORWARDED -FOR hedaer,以防止代理服务器后面的cookie被盗.

如果您正在处理敏感数据,则可以在Javascript中生成随机AES密钥,然后将其与使用RSA加密的密码一起发送到服务器.
然后,您可以使整个应用程序使用来自单个页面的加密AJAX请求,而根本不使用auth cookie.

请注意,如果没有SSL,则无法防止活动的中间人攻击.活跃的攻击者可以使用自己的代理完全替换您的站点,并且没有任何方法可以防御它.(因为没有任何已知的好代码)

实际上,我没有看到这种方法如何阻止中间人攻击. (4认同)
这篇文章应该改变,这是Cargo-Cult的安全性.http://matasano.com/articles/javascript-cryptography/ (3认同)
除了RSA [无法在客户端安全地完成](http://www.matasano.com/articles/javascript-cryptography/).所以这一切都无济于事...... (2认同)

Answer 6

Rem*_*anu 6

您可以使用HTTP摘要式身份验证,大多数浏览器都支持该身份验证,并且不会通过网络明确发送密码.

缺点是broswer显示的丑陋的登录框.如果您坚持使用表单,那么您可以在表单authnetication中实现与HTTP Digest完全相同的协议:发送包含领域和挑战的隐藏字段,并让客户端在JavaScript中添加nonce并计算摘要.通过这种方式,您将使用众所周知且经过验证的呼出协议,而不是使用自己的协议.

HTTP摘要仅需要哈希操作.

归档时间：	15 年，11 月前
查看次数：	33884 次
最近记录：	7 年，1 月前