我正在构建一个简单的 API，它将在一个 android 应用程序中使用（只有大约 3-4 个用户会拥有）。应用程序连接到服务器并发送 GET/PUT 请求。
我已经阅读了我的谷歌搜索，如果您使用 SSL，则以明文形式发送密码而不使用 HMAC 之类的东西对其进行加密是可以的。
但是，人们确实建议您使用“基本身份验证”，它基本上是在 HTTP 标头中以 base64 编码的用户名：密码。如果我使用 SSL，是否有理由不只发送未编码的正文字段“用户名”和“密码”？如果黑客真的想以某种方式通过 SSL，为什么它是使用 base64 编码的呢？当然，如果他能够以某种方式通过 SSL，他将能够进行 base64 解码？
只是想知道我是否应该费心做base64编码，谢谢。
使用 HTTP 身份验证与应用程序特定身份验证之间的区别在于您希望处理身份验证和授权逻辑的位置。
HTTP 身份验证意味着 HTTP 层（apache、nginx、IIS 等）将负责维护身份验证。应用程序授权意味着 Web 应用程序（java、php、django 等）将控制身份验证和授权。
请记住，HTTP 是无状态的。因此，通过添加授权组件，HTTP 可以阻止或允许用户访问某些资源。当您自己没有任何应用程序逻辑时，最有可能使用这种授权。例如，如果您想在 apache 中允许文件目录浏览，但只允许某些用户浏览，您可以修改.htaccess文件以将目录限制为某些用户。
然而，应用程序处理授权逻辑而不是 HTTP 服务器的原因有很多。首先，大多数应用程序处理会话。这是通过使用 cookie 完成的。因此，只有 cookie 值必须重新传输。如果您在应用层处理会话，在这一层处理授权几乎总是更容易。几乎总是首选会话，因为您的应用程序的内容将取决于“谁”在做某事。
使用会话的另一个好处包括隐含的注销功能。因为 HTTP 授权没有会话的概念，所以不能真正注销。忘记凭据将取决于浏览器（或在您的情况下为 Android 应用程序），但服务器无法控制它。即使您的服务器想要强制执行某种注销，它也不能使用 HTTP 授权。
因为基于表单的身份验证通常涉及会话，所以它通常更安全，只要您的资源的安全性依赖于会话。
由于缺少会话，HTTP 基本身份验证比基于表单的身份验证更差。但是，您可以通过使用 HTTP Digest Authentication 获得一些好处，它根据凭据和 nonce 计算散列以避免发送纯文本凭据。因此，在发送明确的凭据或让服务器端应用程序维护会话之间存在权衡。
对于基于浏览器的应用程序，许多人认为在发送凭据之前使用 javascript 计算哈希比使用纯文本密码更好，但这些人错了。为了保护密码，服务器发送它必须运行的客户端代码。但是，如果攻击者能够与客户交谈，他可以用此代码替换他自己的代码。因此，使用 javascript 计算散列的安全优势是如此之小，以至于很少这样做。
由于您提到在 Android 应用程序中使用此 API，因此散列确实有意义。因为您可以使用预定义的客户端例程计算散列，所以使用RFC 2607 中描述的散列机制有明显的好处。不过，我仍然建议在应用层执行授权，因为您想为用户管理会话。
我喜欢告诉人们“HTTP Basic Auth 已被弃用，不要使用它！” 支持基于表单的身份验证。但是，通过 SSL，它在传输中确实是安全的，并且不容易被拦截。在浏览器级别，基于表单的身份验证往往更安全。对于使用 REST api 的 android 应用程序，我建议使用基于令牌的系统。但是，我不会说基于 SSL 的基本身份验证是不安全的。我会称之为“几乎不能接受”。
使用 SHA256-HMAC 之类的东西对密码进行哈希处理的目的不仅是为了保护传输中的密码。在这种情况下，服务器只接收密码的哈希值并对其进行验证。这样一来，哈希实际上就是密码。HMAC 在防止攻击者轻松发送相同哈希的基础上增加了额外的安全性。
对密码进行散列可确保服务器永远不会知道用户的密码实际上是什么。所以，如果数据库被盗，用户的密码至少不能被逆向工程。
请注意，正确实现这一点需要为每个用户使用唯一的盐“加盐”哈希，以防止使用“彩虹表”进行攻击。如果您打算实施密码散列，请对此进行研究。