【问题标题】:Securing Communication between App and Webservice by token通过令牌保护应用程序和 Web 服务之间的通信
【发布时间】:2020-11-12 10:42:26
【问题描述】:

我正在编写一个与网络服务器通信的安卓应用程序。

到目前为止,我掌握了通信基础知识和基于令牌的身份验证系统。 令牌真的很长,但我仍然害怕,有人可能会猜到它们。 所以我想到了类似下面的东西。这是一种有效的方法吗?

我的想法:

  1. 应用生成 RSA 密钥对。
  2. 通过 ssl 使用邮件和密码登录(向服务器提供公钥)
  3. 服务器生成唯一令牌
  4. 服务器保存令牌和公钥
  5. 服务器向应用返回令牌
  6. 从现在开始,应用程序使用令牌,但使用私钥加密所有消息。
  7. 服务器收到带有令牌的消息。它尝试使用公钥解密数据,以确保此消息来自原始登录。如果无法解密,则拒绝请求。

这是一种有效的方法吗?还是这个方法太弱了?

【问题讨论】:

  • 您试图解决或缓解的问题或威胁是什么?这个设计中实际使用的令牌是什么,是客户端标识符吗?
  • 没错!我考虑过使用它作为标识符,就像它在 web 开发中的令牌中很常见。最后我用 PKCE 跑过 Oauth2 并选择继续走这条路,因为它似乎正是我试图在这里归档的内容。

标签: security token rsa


【解决方案1】:

嗯,你想做的是一种可能的方法。以下是我对您的想法的一些想法。

  1. 链条与最薄弱的环节一样坚固。您是否考虑过当用户丢失设备时如何重置访问权限?凭证够用吗?访问邮箱是否足够?攻击者会选择最容易的目标。
  2. 您的方法看起来与mutual authentication with TLS 非常相似。好吧,如果你愿意,你可以重新发明轮子,但我可能会坚持标准。你不想解决例如问题。回复攻击预防,你呢?
  3. 为什么不简单地使用带有 TLS 通道保护的 2FA?例如,U2F 甚至比拥有私有客户端 TLS 密钥更强大。
  4. 使用 RSA 密钥加密长消息很慢。您通常只使用 RSA 加密对称密钥,而使用 AES 加密消息的其余部分。

希望这能有所帮助。

【讨论】:

  • 非常感谢。您的回答非常有帮助,我会接受它作为解决方案。结果出来了,我在这方面投入了更多时间,最后选择了 Oauth2 和 PKCE,因为这似乎符合我的要求并且有更多的改进。我想没有理由重新发明轮子。
猜你喜欢
  • 1970-01-01
  • 2013-06-25
  • 1970-01-01
  • 2018-01-08
  • 1970-01-01
  • 1970-01-01
  • 2019-11-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多