我最近一直在查看应该是安全的 iPhone 应用程序用于工作相关任务的流量，我注意到该应用程序在与后端交谈时不使用任何形式的 session ID/ token 。每个请求都包含用户名、密码和设备 ID，所有流量都通过 https 发送。这是一个restful api，所以没有状态服务器端。
我真的觉得这是一个坏主意，但我想不出太多好的论据来解释为什么。
如果您是中间人攻击的受害者，攻击者在大多数情况下可以在您登录时找到您的密码，因为无论如何都需要将用户名和密码发送到服务器以获取 session ID/ token 。
更好的方法可能是发送用户名、时间戳以及时间戳和密码的哈希值。如果时间戳是 x 秒，则该服务器会丢弃该请求，并且不必通过网络发送明文密码。
然而，我看过的大多数应用程序(除了那些使用 oath 等的应用程序)只是以明文(通过 https)发送用户名和密码来获取 token 。每次启动应用程序时都会发生这种情况(用户名和密码都存储在应用程序数据中)。
正如主题所说，如果使用 https，为什么将用户名和密码从移动/网络应用程序的每个请求发送到后端 api 是一个坏主意？
最佳答案
嗯，你自己说的。您必须将用户名和密码存储在设备本身上。这些凭据存储的安全性如何？安装在设备上的恶意应用程序是否能够检索凭据？如果恶意应用程序与有效应用程序在同一帐户下运行，它可能可以。即使您将这些凭据加密存储，您也必须将 secret 存储在设备本身上。
此外，移动设备丢失/被盗的可能性要高得多，从而使攻击者可以访问设备本身。
另一个原因是每次发送用户名和密码都会增加攻击面。它将为攻击者提供更多具有恒定数据的消息以尝试解密。
最后，验证密码在正确实现的情况下应该相对较慢，这使得 API 身份验证不太理想。
像 OAuth 2.0 这样的协议(protocol)使用在有限时间内有效的访问 token ，您必须有权访问刷新 token 才能获得新的访问 token 。如果设备丢失或被盗，可以轻松撤销刷新 token 。
关于api - 为什么在移动应用程序和后端 api 之间的每个请求中发送用户名和密码是一个坏主意？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27136934/