这可以被认为是安全的吗？
#1 楼
HTTP基本身份验证存在一些问题：密码以base64编码通过网络发送（可以轻松转换为纯文本）。
密码发送针对每个请求反复进行。 （较大的攻击窗口）
网络浏览器将缓存密码，密码长度至少应为窗口/进程的长度。 （可以通过对服务器的任何其他请求以静默方式重用，例如CSRF。）
如果用户要求，密码可以永久存储在浏览器中。 （与上一点相同，此外，它可能还会被共享计算机上的另一个用户窃取。）其中，使用SSL只能解决第一个问题。即使这样，SSL也仅在网络服务器保护之前-任何内部路由，服务器日志记录等都将看到纯文本密码。
因此，与查看所有图片一样，这很重要。
HTTPS可以保护传输中的密码吗？是的。
就足够了吗？通常不会（我想说的是，永远不会-但这实际上取决于您的网站是什么以及网站的安全性。）
评论
实际上，即使使用HTTP Digest，您也可以对密码进行哈希处理（md5（username：realm：password），有时称为HA1）。
–布鲁诺
2011年5月18日20:58
@ AviD♦请注意，3）和4）对REST API很少有效。
– Eugene
2012年6月22日19:55
@KimGysen用于基本身份验证，密码不会传输或存储在cookie中，而是在授权：请求标头中发送，并存储在浏览器内存的特殊（受保护）部分中。并非我不同意您的看法，在一般情况下不应该使用基本身份验证，但是在某些情况下可能需要进行权衡。
–AVID♦
2014年11月28日在8:38
除了“更大的攻击窗口”外，没有诸如帐户锁定之类的内置机制可以防止暴力破解。
– Alex Kuhl
15年3月6日在16:08
@Artjom：在每个请求上发送基本凭据是一个问题，这不是因为您必须继续发送凭据，而是因为在每个请求上都会发送相同的字符串。还有其他身份验证机制，例如HMAC，其中Authorization标头无法解密回用户的秘密，并且服务器可以在不真正知道用户秘密的情况下对请求进行身份验证。在这种机制下，在Authorization标头上发送的字符串会根据请求的哈希值进行更改。
– Lie Ryan
15年8月6日在14:28
#2 楼
尝试这样考虑：当您使用SSL登录任何网站时，最有可能通过HTTPS以纯文本格式传递密码（例如GMail）。唯一的区别-Auth使得用户名/密码在请求标头中传递，而不是在请求正文（GET / POST）中传递。通过HTTPS进行基于表单的身份验证。
评论
这两种情况之间略有不同：使用http基本身份验证为每个请求发送密码，而使用基于表单的登录名仅发送一次，然后使用会话cookie之类的东西。这非常轻微地减小了攻击面。
–佩平·施密兹（Pepijn Schmitz）
15年11月4日在10:51
用户密码仅发送一次，但auth cookie也会在每个请求中发送，因此问题仅是发送用户名和密码，而不是cookie auth
–deFreitas
16年2月8日在12:46
@deFreitas，因此您具有OAuth的前提：使用另一个令牌进行身份验证，而不是一直发送u / p。
– cottsak
16 Mar 2 '16 at 5:27
我认为有一点点不同：在POST形式的示例中，必须在用户决定输入其凭据并将其POST回（安全）之前，通过HTTPS发送初始页面呈现。使用HTTP基本身份验证，即使服务器拒绝服务非HTTPS请求并重定向到HTTPS，凭据也已经不安全地通过了网络，因此对于MiTM侦听非常有用。客户端必须决定最初发布POST HTTPS或冒不安全通道的风险。对于POST形式，这种可能性较小。
– cottsak
16 Mar 2 '16 at 5:30
@PepijnSchmitz我要注意的是，会话密钥（可以失效）的区别与登录凭据被盗相比有很大不同。当另一方拥有您的私用会话密钥时，仍然可以造成损坏，但是它的性质要受限制得多，尤其是因为您可以在应用程序完成执行以使密钥无效之后从API中注销。
–加里（Jeremy Kato）
16年8月5日在18:12
#3 楼
通过HTTPS进行基本身份验证是很好的，但是它并不完全安全。类似于Fiddler进行SSL调试的工作方式一样，公司HTTPS代理管理Web浏览器和代理（其IP地址出现在Web服务器日志中）之间的连接。在这种情况下，HTTPS密码将被解密，然后在公司代理中重新加密。取决于谁管理代理以及如何使用其日志，从您的角度来看这可能是可接受的，也可能是坏事。
有关SSL拦截方式的详细信息完成后，请参见以下链接：
SSL代理拦截SSL
连接时，它将向客户端提供模拟的
服务器证书
浏览器。客户端浏览器向最终用户发出
安全弹出窗口，因为该浏览器不信任ProxySG使用的
发行者。如果将SSL代理使用的颁发者
证书作为
客户端浏览器的证书存储区中的受信任根导入
，则不会出现此弹出窗口。
ProxySG通过其管理控制台使所有已配置的
证书可供下载
。您可以
要求最终用户通过Internet Explorer
或Firefox下载颁发者证书，然后将其作为受信任的CA安装在他们选择的浏览器中。这
消除了
模拟证书的证书弹出窗口...
一些公司通过部署根证书（通过GPO到每个工作站）。尽管这只会影响使用Microsoft证书存储的软件。 Firefox之类的软件需要进行不同的更新。
评论
实际上，这取决于您正在谈论的站点。例如。如果您下班时浏览到您的银行，并且他们使用基本身份验证，则在您的工作中不会被代理解密。 SSL正是通过这种方式。
–AVID♦
2010年12月6日下午6:16
反对派选民应阅读链接的文档，因为这是一个鲜为人知的真实有效的观点。文件：bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf
–半比特
2010-12-7 3:40
是的，您是对的-BlueCoat确实看起来像公司恶意软件，使用FUD来使业务不安全。
–AVID♦
2010年12月7日9:00
顺便说一句-Chrome确实使用Windows证书存储...
–AVID♦
2010-12-7 9:01
@AViD，在某些情况下，公司代理实际上会通过提供自己的证书（由内部公司证书签署，并作为所有公司工作站上的受信任根权限证书导入）对SSL流量进行解密。我的公司针对包括Gmail在内的一些网站（但不适用于银行网站）执行此操作。它可以工作，并且通常对用户不可见，因为该公司还管理台式机/浏览器。请注意，严格的运输安全（HSTS）可以克服这一问题……正是firefox HSTS警告使我首先意识到了这一点！
–迈克尔·卢卡斯（Michael Lucas）
2015年12月17日17:28
#4 楼
您注意到需要对客户端进行身份验证，并询问通过SSL的HTTP基本身份验证的安全性。这就是SSL的设计目的，只要密码是一个好的密码，它就可以正常工作。如果您确实是为单个客户端设置的，则可以通过选择一个较长的随机密码来轻松确保这一点，例如使用良好的随机性源或本网站上讨论的其他技术可以输入12个字符。在您所描述的情况下，如所引用的python ssl页所述使用自签名证书就可以了。评论
如果要进行自签名，请确保传达证书的SHA1和MD5指纹，以便他们可以在连接时验证其合法性。或提前分发（如果可行）。
–朝木
2012年7月14日在3:27
使用HTTP基本认证还有另一个问题：完整的密码通过SSL隧道发送。换句话说，密码在提交之前不会被散列，因此有可能被捕获（错误在您的应用程序代码中，等等）。这通常不是主要的问题（对于您通过HTTPS提交的大多数密码，甚至在网站登录表单中，甚至在SSH密码中，这都是正确的），但是值得一提。
–克里斯·库尔（Chris Kuehl）
2012年7月14日下午4:43
@ChrisKuehl没有反对在客户端javascript中进行任何加密的有力论据吗？那是你的建议吗？在我看来，TLS除了支付签署证书的费用外，几乎和我所能得到的一样好。
–陆even
2012年7月14日在9:23
@StevenLu不是我知道的或者我可以很快找到的，但是我会对阅读有关该主题的任何内容感兴趣。我看不到有任何办法可以在将其发送到服务器端之前先对其进行哈希处理，这会降低安全性，即使服务器端在存储之前进一步对其进行哈希处理也是如此。我很想使用SSL / TLS身份验证来代替（现代浏览器允许对使用密钥身份验证的网站进行双向身份验证），尤其是对于那些不希望普通用户查看的页面。但是，这在很大程度上取决于您的用例，并且对于Python Web服务器来说可能很困难。
–克里斯·库尔（Chris Kuehl）
2012年7月14日在17:08
@StevenLu很有趣，但是没有讲到重点；在浏览器中实现的TLS身份验证不涉及JavaScript。这是浏览器本身的功能。有一些问题使其不适用于面向用户的身份验证，但是对于开发人员/管理员而言，我认为有很充分的理由。
–克里斯·库尔（Chris Kuehl）
2012年7月14日23:00
#5 楼
完全取决于其安全性。通过ssl进行的基本身份验证仍将以纯文本形式发送凭据，这意味着您只有一层保护。将身份验证传递给受信任的第三方。#6 楼
许多大型和流行的站点都通过HTTPS使用基本（或其他基于表单的）身份验证。它通常会引起安全意识敏锐的人们的“叹息”。您可以在客户端对哈希密码进行哈希处理，而是发送哈希值吗？那样会进一步提高标准。在使用RESTful API的情况下，您可能没有登录页面，所以没关系。如果可以，请使用一些免费的安全工具（例如Watcher和Skipfish）验证您的应用程序。评论
只有带有哈希的质询响应才是安全性的升级，否则，攻击者可以仅监听哈希并在会话到期时仍然获得访问权限
–休伯特·卡里奥（Hubert Kario）
2011年7月19日在22:14
#7 楼
我将自己用于很多事情，只要您不忽略浏览器中的任何TLS警告，您都应该会很好。加密。它可以像提交任何密码形式一样安全。我建议使用Let's Encrypt，而不是使用自签名证书。它们提供免费证书，并且受到Microsoft，Mozilla等的信任，因此不会在浏览器中发出TLS警告。我认为最好使用此证书代替自签名证书。如果您看到TLS错误，就知道它是真实的，而不仅仅是因为您的证书是自签名的。
评论
我绝对会做这样的事情，特别是如果它是免费的。 “无效证书”错误非常明显。
–陆even
2012年7月15日在1:08
是的，StartSSL确实是一种自制的解决方案，但是它受到了大型团体的信任，因此，我想只要您不保护任何价值数百万美元的东西就可以了。任何事情都比自签名证书更好。使自签名安全的方法是检查指纹，但是您仍然可以在使用（例如）StartSSL时执行此操作。
–吕克
2012年7月15日在17:59
我将安全内容托管在另一台服务器上，该服务器可以为证书设置目标域（由StartSSL颁发）。这是因为我没有为带有静态IP的VPS付费，而是使用No-IP服务来重定向到我的IP。我是否可以获取密钥/证书，使我可以从任何地方打开我的网站而不会显示无效的证书错误？
–陆even
2012年7月17日在3:54
因此，对我来说似乎很清楚，使用动态IP绝对无法设置适当的SSL证书。好的，我想我当时会遇到浏览器错误（除非我进行某种代理设置）。
–陆even
2012年7月17日在4:02
@starbeamrainbowlabs谢谢！我更新了答案。
–吕克
17年12月17日在12:35
#8 楼
到目前为止，我还没有提到的另一个论据是，许多智能手机等移动设备在浏览器中通过HTTPS进行基本身份验证时，不允许用户检查证书。这意味着与基于表单的身份验证不同，您不能绕过基本身份验证弹出窗口，该弹出窗口是大多数移动平台上的模式对话框，用于在输入凭据之前检查证书。当攻击者使用有效证书时，这可能会带来风险。#9 楼
这是历史的更多背景。就像其他人说的那样，如果您可以承受一些限制，那么基于TLS的基本身份验证就可以很好地发挥作用。在后端，基本身份验证的性能不错，但完全依靠TLS来保证机密性和完整性。它类似于基于令牌的身份验证。如果您还需要其他声音，请考虑使用签名方案或TLS客户端身份验证。
评论
是的，http用户名/密码通过SSL时可以，但是密码必须很长。好吧，我可以在服务器中添加一些逻辑，以禁止尝试过多密码的客户端。这样可以防止DoS和密码猜测吗？