保护API：SSL＆amp; HTTP基本身份验证与签名

Question

在为我们的网络应用设计API时，我们会将其子域用作“用户名”并生成API密钥/共享密钥。首先，可以使用子域作为用户名吗？我没有看到生成另一个密钥的好处。

不同的API似乎做两件事之一：

1. 使用带SSL的HTTP基本身份验证

在每个请求中，用户名设置为子域，API密码设置为API密钥。由于我们使用SSL，因此这应该是安全的欺骗。

值得注意的API： Google Checkout，Freshbooks，GitHub，Zendesk

1. 使用共享密钥创建请求的签名

通常通过对键/值对进行排序并使用具有共享密钥的HMAC-SHA1来生成签名来实现。然后签名随请求一起发送，并在另一端验证。

值得注意的API： Google Checkout，Amazon AWS

PS：没错，Google Checkout同时支持

修改：请注意，OAuth 2正在删除签名，转而使用SSL发送用户名/密码。

任何人都有关于选择什么的意见：SSL vs Signature？

Answer 1

基于SSL的HTTP基本身份验证对我的研究非常安全。

毕竟，使用SSL（现在严格为TLS）意味着传输层已加密，我们可以安全地假设通过此传递的任何信息都是安全的，并且没有被篡改。

因此，在不生成签名的情况下传递用户名和密码就足够了。

Answer 2

伊戈尔的答案并非完全正确。尽管TLS确实确保传输层是加密且安全的，但它仍然不如使用例如具有相互认证的TLS那样安全，其中客户端使用数字签名形式的“强加密”进行认证。有两个主要原因导致这仍然优于基于TLS的基本身份验证：

• 密码是密码，我假设现在我们这个星球上70亿人中有三个使用完全随机的30个字符的密码。我们其他人选择了熵少得多的东西。因此，攻击者更容易对使用密码而非数字签名的服务进行暴力破解。

• 有人可能会争辩说，对于客户端数字签名，还会涉及密码，通常用于访问私钥。但这与我们使用Basic Auth的情况完全不同：首先私钥作为客户机器上的资源存在，所以即使它被恢复它只会影响一个人而不是每个人，其次是典型密钥容器格式如PKCS＃12还有用于访问密钥的基于密码的加密。这些算法专门设计用于减慢攻击者的速度以降低每单位时间的暴力尝试率，这也是数字签名的一个优势。

毫无疑问，TLS Basic Auth设置和使用起来要方便得多，但对于高安全性环境，我总是喜欢“强加密”而不是用户/密码解决方案，这是值得的。

Answer 3

只要存在某种形式的秘密，就可以使用子域名作为用户名。

使用共享密钥的好处是，执行请求的“方”不需要知道秘密，它只需要知道签名来执行请求。例如，如果您希望用户允许通过浏览器发出请求，这将非常有用。

使用S3，您可以创建签名，将其发送到浏览器并直接从浏览器上传到S3。

您也可以使用HTTP摘要，它可以从两者中获益。您仍然可以在浏览器中轻松测试API，因为浏览器支持Digest和Basic，并且永远不会通过网络发送纯文本密码。

Answer 4

OpenSSL的Heartbleed问题说明了仅依靠SSL来保护API的潜在缺陷。如果SSL传输受到损害，可能需要采取其他安全措施，具体取决于API的使用和影响，如Emboss的回答所述。

Answer 5

回答旧线程，因为没有人真正触及主要观点

SSL / TLS与所有PKI一样存在根本性缺陷，因为它们依赖于已被证明越来越容易被MiM attacks影响的信任链：

• 证书颁发机构已经并且可以被黑客入侵。其中一个例子是DigiNotar案例，在违反行为被确认撤销所有证书之前，CA已被入侵几个月。与此同时，伊朗政府为google.com，facebook.com，twitter.com等制作了完美有效的SSL证书。

• 像Zscaler这样的公司代理过滤工具，可以为未指定的“安全目的”动态解密和重新加密所有流量。请参阅this question/answer on SO

• 一直在发现具有最常见SSL实现（openSSL）的错误（但随着时间的推移，情况应该会好转吗？）

因此，大型玩家不喜欢仅依赖SSL：

在这些情况下，HMAC令牌不会为您提供保密但不会允许任何监视您的人使用您的凭据伪造请求，否则如果您只是通过基本身份验证传递它们，那将是微不足道的。

PKI模型的替代方案是Web of trust，它不依赖于单一机构来验证证书的真实性，而是依赖于大多数证书提供的意见。    - 已知和可信赖的同行或    - 已知但不一定是受信任的同行

这个模型仍然不完美，因为它受到臭名昭着的51% attack的影响，与比特币区块链完全相同（这是分布式可信模型的一个例子）

Answer 6

我想指出在security.stackexchange.com上提到的一些事情，因为你说“基于SSL的HTTP基本身份验证对我的研究来说是完全安全的”。你可以说下面的第3点和第4点很少对REST API有效，但它实际上取决于它们的实现方式。

“HTTP Basic Auth存在一些问题：

• 密码通过base64编码的线路发送（可以是 很容易转换成明文）。
• 为每个请求重复发送密码。 （更大的攻击 窗口）
• 密码由webbrowser缓存，至少为 窗口/过程的长度。 （任何人都可以默默地重复使用 对服务器的其他请求，例如CSRF）。
• 如果用户
  ，密码可以永久存储在浏览器中 要求。 （与前一点相同，另外可能会被〓偷走 共享计算机上的另一个用户。）

其中，使用SSL只能解决第一个问题。即便如此，SSL只会保护，直到网络服务器 - 任何内部路由，服务器日志记录等都会看到明文密码。

所以，就像看待整个画面一样重要。 HTTPS是否在传输过程中保护密码？ - 是的。

这够了吗？通常，没有。 （我想说，永远不会 - 但这实际上取决于您的网站是什么以及它需要多么安全。）“