我的 iOS 应用程序和我的 API 之间的合理安全级别是多少

Question

我目前正在努力提高我编写的 iOS 应用程序和我编写的 PHP API 之间的安全性。

看似重要的参数：
- 我正在使用 AFNetworking
- 我已经在使用 HTTPS
- 我已经在使用托管公司的证书

这是一个聊天/消息应用程序。不计费。没有需要额外预防措施的数据。只是用户名和密码。

我正在尝试确定对 iOS 应用的合理尽职调查。

我一直在阅读有关 oAuth 1a 的信息（很多人似乎不喜欢 oAuth2？）

oAuth 体验的“消费者”客户端部分（使用 AFNetworking 时）似乎涉及访问网络浏览器并通过自定义 URL 协议返回应用程序。这对我来说似乎是可怕的用户体验。

我知道我无法控制哪个客户端正在访问我的 API。 我知道存在局限性并且没有完美的解决方案。

我只是想在更高的层次上找到什么是“最佳实践”？从某种意义上说，其他人在查看您的应用时会认为“这似乎是合理的”是可以接受的。

我知道 SO 并不总是能很好地处理像这样的开放式主观问题，但它确实是我正在寻找的。普遍的共识是什么？

如果这不是可以在这里回答的问题，有人可以给我指出一个更好的地方来寻找答案吗？非常感谢。

Answer 1

关于安全性的重要一点是把它放在上下文中：“保护免受什么攻击，以什么为动机，以什么代价？”

• HTTPS：阻止被动窥探者。费用：最低。
• 带有证书验证的 HTTPS：阻止琐碎的主动拦截器。费用：次要。
• 带有证书固定的 HTTPS：阻止无法冒充您的证书供应商的活动拦截器。费用：有点涉及。

奖励积分：在具有临时密钥的安全性中使用证书或密码 - 这意味着即使有人稍后获得您服务器的密钥，如果他们有录音，他们也无法返回阅读已经说过的内容。

“聊天”对于拦截来说非常有价值——尤其是在监视用户是常态的国家。加倍如此群聊。聊天绝对不是基本的“无价值数据”案例。里面有大量有价值的数据和元数据。

OAuth1 和 OAuth2 是授权框架：它们有助于描述和系统化谁有权访问什么。而已。它仅在三方系统中有用：当委派有权访问的组与请求或允许访问的组分开时。整个“授权此应用在我的帐户上发布”按钮是规范功能。 OAuth1 使用令牌和加密技术来实现，实施起来有点糟糕，但非常可靠。 OAuth2 只是一个臭烫的烫手山芋，它不是一个可互操作的标准，标准流程中的管家已经否认了。

艰苦的分析工作是“从谁那里得到保障，以什么动机？” -- 有各种各样的攻击，从简单的垃圾邮件和滥用到主动拒绝服务、主动闯入服务器和主动拦截通信。

用户名，如果无论如何都公开显示，主要是隐私问题——“某人希望被称为用户的范围有多大？”如果此应用程序有社交方面的内容，也许他们与谁有联系。

密码受到多种方式的攻击。

• 蛮力：会猜出愚蠢的密码。
• 服务器入侵：如果您没有在服务器中存储经过哈希处理和加盐处理的密码，那么获得该列表的人就可以轻松获得这些密码，甚至不必破解它们。我保证用户将为您和他们的银行使用相同的密码。它发生了。
• 密码重置攻击——安全问题很少像密码那样安全。电子邮件可以被欺骗。密码重置系统通常会留下一个可用于重置的令牌。小心。

这些只是我脑海中突然出现的事情。