如何实现移动应用的高安全性?

发布于 2024-12-12 02:11:08 字数 713 浏览 0 评论 0原文

自从开始了解移动计算以来,我经常错过有关安全性的讨论。然而,在我看来,这是移动计算的一个主要话题。开发安全的移动应用程序有几个方面:

  1. 如何在设备和服务器之间创建保存通信
  2. 如何识别设备以及如何在移动设备上验证用户?
  3. 如何处理设备被盗的可能性以及随后滥用设备上存储的数据和授予设备的访问权限?

可能还有更多,但我认为这些是关键问题。到目前为止我已经想出了这个解决方案:

  1. SSL。
  2. 使用OAuth授予对设备的访问权限,然后存储AES加密的访问令牌。在允许用户访问应用程序之前,通过请求解密密钥(很可能是 PIN,因为这些在移动设备上更容易输入)来检查用户的身份。
  3. 如果数据存储不可避免,请使用AES 加密。使用 2 中提到的密钥,或者将解密密钥存储在服务器上,并让应用程序每次都从那里请求它。如果被盗,请撤销 OAuth 密钥。 (这也将防止窃贼从服务器检索解密密钥。)

您是否发现这种方法有任何缺陷或认为该策略有任何可以改进的地方?我试图在可用性和安全性之间找到平衡,因为它们似乎是对立的概念。

注意:这是一个一般概念,不是专门为某个操作系统设计的。

Since starting to learn about mobile computing I frequently missed discussions about security. However, it seems to me that this is a major topic for mobile computing. There are certain aspects to developing a secure mobile application:

  1. How to create save communication between device and server?
  2. How to identify a device and how to authenticate a user on a mobile device?
  3. How to handle the possibility of device theft and ensuing misuse of data stored on the device and access granted to the device?

There are probably more, but those are the key questions, I think. So far I have come up with this solution:

  1. SSL.
  2. Use OAuth to grant access to the device, then store the access token AES-encrypted. Check the user's identity before allowing him access to the app by requesting the decryption key (most likely a PIN as those are more easy to enter on a mobile device).
  3. If storage of data is unavoidable, use AES encryption. Either use the key mentioned in 2. or alternatively store the decryption key on the server and have the app request it from there every time. In case of theft revoke the OAuth key. (This will also prevent the thief to retrieve the decryption key from the server.)

Do you see any flaws in this approach or see any points where the strategy could be improved? I tried to find a balance between usability and security, as it seems they are opposing concepts.

Note: This is meant as a general concept, not specifically designed for one operating system.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

又怨 2024-12-19 02:11:09

这是开放式的并且非常笼统,所以 SO 可能不是最好的地方。您真的认为可以用 3 个要点来概括这一点吗?如果不指定具体的指导方针、参数和实践,您甚至无法尝试承诺安全性。

  1. “使用 SSL”本身没有任何意义。有一百种滥用 SSL 的方法:信任每个证书、使用弱密码、使用易受攻击的协议版本(SSLv2 等)、不检查吊销等。
  2. 使用 AES 也不能保证太多:您可能会如果你使用 ECB 模式,或者在 CBC 模式下重复使用相同的 IV,或者你的 IV 不是真正随机的(真实的例子:TLS 试图用这个模式偷工减料),等等,等等
  3. 。你的加密密钥服务器,这只是另一种攻击媒介:您真的信任服务器(您如何确保它是您自己的服务器?)来存储/管理您的密钥吗?

所以,是的,有很多潜在缺陷,答案很简单:事情没那么简单。

This is open-ended and very general, so SO might not be the best place. Do you really think you can summarize this in 3 bullet points? You cannot even try to promise security without specifying concrete guidelines, parameters and practices.

  1. 'Use SSL' means nothing by itself. There are a hundred ways to misuse SSL: trust every certificate, use weak ciphers, use vulnerable protocol versions (SSLv2, etc.), don't check revocation, etc., etc.
  2. Using AES doesn't guarantee much either: you might be open to attacks if you use ECB mode, or re-use the same IV in CBC mode, or your IV is not truly random (real example: TLS tried to cut corners with this one), etc., etc.
  3. If you store you encryption key on a server, that's just another attack vector: do you really trust the server (how do you make sure it's your own one?) to store/manage your key?

So, yes, lots of potential flaws, and the answer is simple: it's not that simple.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文