我正在构建一个Android应用程序，该应用程序在后端使用了我的REST API。首先，我需要构建一个注册和登录API。在Google搜寻了一段时间之后，我觉得只能采取两种方法。
在注册期间，我使用https并获取用户的凭据；根据用户名（服务器端）将其保存在我的数据库中。在登录期间，我再次使用https，并询问用户的凭据；验证数据库上的哈希密码，然后向他返回一个会话ID，除非他注销，否则我打算永不过期。此外，用户进行的任何其他API调用（GET / POST）都将带有该会话ID，以便我可以验证用户。
但是在上述方法中，我被迫使用https进行任何API调用，否则我很容易受到“中间攻击者”的攻击，即如果有人嗅探我的会话ID，他可以重建类似的内容我不想要的GET / POST请求。我对上述假设是正确的吗？
第二个选择是遵循Amazon Web Services的路径，在该路径中我使用公钥/私钥身份验证。用户注册时，我使用https API将其凭据保存在数据库中。从那时起，我将用户的哈希密码用作私钥。用户进行的任何其他API调用都将使用用户的私钥具有请求URL的散列Blob。在服务器端，我使用保存的私钥重建哈希。如果哈希匹配，我让用户执行任务，否则拒绝。在此选项中，我只需要对注册API使用https。 REST可以在http上进行。
但是这里的缺点是，我被迫将我的注册API托管在一个单独的虚拟目录中（我使用的是IIS，但不确定是否可以同时托管http和https API在同一虚拟目录中）。因此，我不得不在单独的项目文件中开发Registration API。同样，我对上述假设是否正确？
编辑：我正在使用ASP.NET MVC4来构建Web API。
我不愿意对所有REST API调用使用https的原因是，我觉得它不轻巧，可以创建更多内容网络有效负载，可能不是最适合移动应用程序。进一步的加密/解密和额外的握手可能会进一步影响手机的电池寿命吗？还是不重要？
您会建议上述两种方法中的哪一种？
PS：我们到处都使用Https，这是最好的决定。我的博客上有更多内容。
#1 楼
我会在所有地方都使用SSL / TLS（因为您可以控制双方，因此强制使用TLS 1.2应该是可行的）。它使用起来相对简单，并且免费提供了许多安全功能。例如，如果您不使用SSL，则需要担心重放攻击。如果您担心性能，请确保服务器和客户端均支持会话恢复。这使得以后的握手要便宜得多。由于与实际数据的加密相比，握手在SSL中非常昂贵，因此可以大大降低总体负载。
如果使用HTTP 2，您甚至可以通过单个连接发送多个请求，这样您可以避免在以后的请求中进行完整的TCP和SSL握手开销。
评论
但是网络负载呢？如果我将其用于所有操作，会不会在网上传输更多数据？考虑到手机有限的带宽，对于交互式应用程序来说还是个好主意吗？
–noob妈妈
2012年9月9日上午10:31
SSL网络开销似乎不太可能相关。但是，如果您对此表示怀疑，请进行测量。握手的成本为几kB，每个数据包的开销为几十个字节。
– CodesInChaos
2012年9月9日上午11:24
HTTP / 1.1可以通过一个连接执行一系列请求，尽管许多服务器（和代理等）和某些客户端在空闲时间过长（可能从几秒到几个小时不等）时不会保持打开状态； HTTP / 2添加的是多个* concurrent * / overlapping请求。
–dave_thompson_085
15年11月10日在16:50
#2 楼
我建议使用OAuth。如果您不熟悉它，那么一定要仔细阅读。此外，您还可以使用第三方身份提供者，因此您的用户可以将其Google / Windows Live /等帐户用于您的应用程序，从而避免注册。即使您想滚动自己的帐户自己的身份验证框架，我不建议使用未过期的会话。会话应在足够的空闲时间后过期，否则这将为漏洞利用提供更多空间（例如，会话劫持）。
评论
我研究了OAuth，当我想让用户使用Google / Windows / etc登录我的应用程序时，它很有用。证书。但是我是否也应该给他们选择仅为我的应用程序注册的选择？此外，我看到您对会话劫持的观点，有趣，..我从没想过！
–noob妈妈
2012年9月9日在8:57
您还可以在服务器端集成OAuth，因此您的用户可以仅为您的应用程序注册一个帐户。它不仅有用，因为您可以使用第三方身份提供者，而且有用，因为它是您可以依赖的非常好的，强大的身份验证框架。另一方面，对于一个简单的应用程序来说，它可能太复杂了，但这由您决定。
– ZsomborErdődy-Nagy
2012年9月9日上午9:08
嗯..顺便说一句，我之所以想不使会话期满是因为大多数应用程序（例如twitter和Pinterest）都没有注销选项。我也假设会话永不过期。
–noob妈妈
2012年9月9日上午9:20
+1代表OAuth建议。但是，我非常不同意关于未到期会话的评论。在移动平台上，非到期会话对于大多数目的来说非常有用。不要强迫用户在移动键盘上重复输入密码（这很麻烦！不仅会带来不便，还会导致用户选择较弱的密码，从而损害整体安全性）。就个人而言，我建议您使用不过期的会话，这是获得安全性和便利性的绝佳方法。
– D.W.
2012年9月10日下午0:53
值得一提的是，OAuth必须通过安全通道（例如HTTPS）完成。如果您在没有HTTPS或其他安全通道的情况下执行OAuth，则整个安全性将受到损害...
– Sean Burton
17-10-16在17:42
#3 楼
取决于其安全性。每次使解决方案变得更加复杂时，您也可能会留下一个漏洞。最好使用某种行业标准的授权和身份验证模块。只要您满足以下条件，您就可以了：
加密密码（使用AES或Blowfish之类的东西）
输入密码
通过HTTPS发送数据
OAuth的替代方法。
如果有人想入侵您十分糟糕的是，他们总是会找到方法。秘诀是增加所需的时间和精力，以至于不值得有人花时间去做。因此，如果您没有大量的客户和/或财务数据，并且您不是一家引人注目的公司，那么像上面这样的标准安全性实现就可以了。
评论
密码永远不要加密。密码必须始终是哈希值。 AES和BLowfish不适合用于密码存储。您需要PBKDF2，bcrypt，脚本。 （即使是损坏的哈希函数md5，也比AES的密码存储更好。）
–rook
2012年9月9日在22:05
#4 楼
在JEE中，我们有容器管理安全性的概念。在这种情况下，我将我的静态服务设置为使用基本身份验证，默认情况下，该身份验证是针对应用服务器上设置的领域使用HTTP密码身份验证。这样就无需使用HTML表单登录，也不需要部署客户端证书的复杂性。应用程序仅假设将有一个用户主体，并可能随请求一起传递其他数据，例如标识详细信息。这包括宁静的API。
在我的设置中，我实现了OAuth2 JASPIC服务器身份验证模块[源]，该模块存储经过对称加密的OAuth令牌，密钥驻留在服务器中，该密钥在cookie中的寿命也有限，并且将其用作应用程序的身份验证。
通过执行上述操作，我使应用程序远离身份验证语义，并且当我想使用Selenium执行功能集成测试时，这是一个奖励，我可以降级为使用HTTP密码，而不必进行复杂的测试一直连接到OAuth提供程序。
此外，我仍将使用SSL来确保至少您的传输安全。不使用SSL只会增加处理应用程序常见攻击的复杂性。
请记住，这是JEE，但是该机制可以应用于任何技术。
#5 楼
您永远不会百分百确定自己的API是安全的。这样做的主要原因是，您可能会将二进制文件交给了可以正常工作的客户。这样一来，他们就可以在世界范围内遍历该二进制文件，以在其上查找密钥/秘密，以用于在您的API服务器上安全地进行身份验证。客户端API端点是最薄弱的地方，因为它们拥有运行二进制文件的设备，因此它们可以操纵其设备认为有效的证书。
我正在谈论的是这篇文章（“对软件的私有API进行反向工程的教程：破解您的沙发”）。最后，我想引用其中的最后一个段落来完成此答案：
是否有可能完全阻止第三方客户端使用私有API？ ？我不这么认为。如前所述，使用SSL固定将防止
使用简单的透明代理技术
嗅探到API请求。最后，即使您混淆了二进制文件，具有某些资源和时间的
动机黑客也总是能够
对应用程序二进制文件进行反向工程并获得私钥/证书。我
认为客户端端点是安全的这一假设本质上是错误的。 API客户端是一个薄弱环节。
#6 楼
仅HTTPS是必须的。在控制应用程序和api的同时，我将实现证书固定。证书固定可以被击败，但这对临时检查员而言是一个很好的威慑。
您可以使用有效负载加密添加另一层。这需要建立一个可靠的密钥分发和密钥轮换过程。
如果您的应用程序使用访问令牌或会话Cookies来授权特定的API，请确保它们超时。我经常观察到承载令牌不会在数天，数月或什至永远不会过期。
黄金法则：移动操作系统是一种恶劣的环境。谨慎对待并缺乏信任。
#7 楼
我觉得它不是轻量级的，并且会创建更多的网络有效负载
它对延迟有一些影响-因此，如果您需要处理10毫秒的数据，那可能是考虑。但是即使在2012年，非常基本的硬件库也可以处理计算开销，而影响却微不足道。 >那么以上不是问题。
评论
这似乎无法回答问题，但会对帖子的一部分发表评论。
– schroeder♦
19年11月8日在22:07
问题基于一个错误的谓词-每个人似乎都忽略了它。
–symcbean
19年11月8日在22:10
可接受的答案中有关于性能问题的整段内容
– schroeder♦
19年11月8日在22:10
评论
在考虑HTTPS时，开发人员通常更关心服务器性能。对于客户端设备，您每分钟发送多少个请求？我认为每分钟几个请求不会有所作为。我之前已经看过它，它有很多有趣的链接，但是没有一个可以完全回答我上面所有的疑问！
您是否对SSL进行了基准测试？关于SSL的最昂贵的部分是握手，您已经需要该握手进行登录。握手通常可以重新用于以后的连接（会话恢复）。
您可以在登录时生成安全令牌，并将在请求时发送它。我从这里获得了详细信息skillrow.com/basic-security-in-rest-api
您的第二种方法并不安全，它无法阻止重放攻击。如果没有所有HTTPS，将很难确保安全性。另外，您避免使用HTTPS的理由也没有道理，这些天的额外开销不足以令人担忧，与不使用HTTPS的安全性相比，无疑是可以肯定的。