问使用“基本HTTP”身份验证的原因是什么？

EN

使用HTTP身份验证与特定于应用程序的身份验证之间的区别在于您希望处理身份验证和授权逻辑。

HTTP身份验证意味着HTTP层(apache、nginx、IIS等)将负责维护身份验证。应用程序授权意味着web应用程序(java、php、django等)将控制身份验证和授权。

为什么有区别？

请记住，HTTP是无状态的。因此，通过添加授权组件，HTTP可以防止或允许用户访问某些资源。这种授权最有可能的使用是当您自己没有任何应用程序逻辑时。例如，如果希望允许在apache中浏览文件目录，但只允许某些用户浏览，则可以修改.htaccess文件以将目录限制为特定用户。

但是，应用程序处理授权逻辑而不是HTTP服务器的原因有很多。首先，大多数应用程序处理会话。这是通过使用cookie来完成的。因此，只有cookie值必须重新传输。如果您正在处理应用程序层中的会话，那么在此层处理授权也几乎总是更容易。几乎所有情况下，会话都是首选的，因为应用程序的内容将取决于“谁”在做什么。

但是我的应用程序可以读取Headers，如果HTTP提供了一种机制，为什么要使用表单呢？

使用会话的另一个好处包括隐式注销功能。因为HTTP授权没有会话的概念，所以不能真正注销。应该由浏览器(或者在您的例子中是Android应用程序)来忘记凭据，但是服务器无法控制它。即使您的服务器希望强制执行某种类型的注销，它也不能使用HTTP授权。

基于表单的身份验证的

安全性

因为基于表单的身份验证通常涉及会话，因此它通常更安全，只要您的资源的安全性依赖于会话。

身份验证

的安全好处

由于缺少会话，HTTP基本身份验证比基于窗体的身份验证更糟糕。但是，使用HTTP身份验证可以获得一些好处，该身份验证针对凭据和非can计算散列，以避免发送纯文本凭据。因此，在发送明确的凭据还是让服务器端应用程序维护会话之间存在权衡。

不能在传输凭据之前在客户端计算散列吗？

对于基于浏览器的应用程序，许多人认为在发送凭据之前使用javascript计算散列比使用纯文本密码要好，但这些人错了。为了保护密码，服务器发送它必须运行的客户端代码。但是，如果攻击者能够与客户端对话，他可以用这段代码代替自己的代码。因此，使用javascript计算散列的安全性好处非常小，很少这样做。

由于您提到在Android应用程序中使用此API，哈希确实是有意义的。因为您可以使用预定义的客户端例程计算哈希，所以使用RFC 2607中描述的散列机制有明显的好处。不过，我仍然建议在应用程序层执行授权，因为您希望管理用户的会话。

我喜欢告诉人们"HTTP是不推荐的，不要使用它！“支持基于表单的身份验证。然而，在SSL上，它确实是安全的在传输中，不容易被拦截。在浏览器级别上，基于表单的身份验证往往更安全.对于使用REST的android应用程序，我建议使用基于令牌的系统。但是，我不会说SSL上的基本auth是不安全的；我将其称为“几乎不能接受”。

使用The 256-HMAC之类的东西来哈希密码的目的不仅仅是保护在传输中的密码。在这种情况下，服务器只接收密码的散列，并对此进行验证。这样，哈希实际上就是密码。HMAC在此基础上增加了额外的安全性，防止攻击者轻松发送相同的哈希。

哈希密码确保服务器永远不知道用户的密码实际上是什么。因此，如果数据库被盗，用户的密码至少不能进行反向工程。

请注意，正确的实现需要每个用户使用唯一的salt来“腌制”散列，以防止使用“彩虹表”进行攻击。如果您计划实现密码哈希，请进行研究。