保护API:SSL和HTTP基本身份验证与签名

Question

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

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

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

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

着名的API:Google Checkout,Freshbooks,GitHub,Zendesk

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

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

着名的API:Google Checkout,亚马逊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设置和使用起来要方便得多,但对于高安全性环境,我总是喜欢"强加密"而不是用户/密码解决方案,这是值得的.