【问题标题】:How to protect client credentials in a desktop app?如何保护桌面应用程序中的客户端凭据?
【发布时间】:2022-08-02 14:09:59
【问题描述】:

我为 YouTube 编写了一个上传器(桌面)应用程序,以通过使用模板来简化上传过程。它已经过验证,我不时要求额外的配额。现在我的应用程序吸引了垃圾邮件发送者的兴趣。在 Google Cloud 平台控制台中,我可以看到我的凭据使用了我不使用我的应用程序执行的 API 请求,例如评价视频、添加订阅和更新频道,而不是少量此类请求。

我已经尝试定期更改密码(这也意味着部署新的​​应用程序版本),混淆二进制文件并修改二进制文件中的凭据字符串,以便无法直接找到它们。但老实说,这不值得,例如使用 fiddler您可以立即在身份验证请求中看到密码(我使用此代码作为基础:https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthDesktopApp/OAuthDesktopApp/MainWindow.xaml.cs)。第二天,垃圾邮件发送者又回来了。

我想知道为什么桌面应用程序根本需要这种双重身份验证,甚至在这里说,在桌面应用程序上它不能保密:https://developers.google.com/youtube/v3/guides/auth/installed-apps 并且所有请求都经过 OAuth 身份验证(一种授予访问权限而不泄露和传输的机制密码,但您需要使用 API 凭据执行此操作 ????)。 YouTube 帐户应该限制配额并禁止滥用而不是应用程序,但这是另一回事......

我还寻找一种限制请求的可能性,以便没有订阅请求是可能的,例如或限制每天的上传量,但我发现的唯一可能性是限制每个用户每分钟的配额,我需要将其设置为 1600 以便上传工作,这没有帮助,因为它仍然足够一天中的垃圾邮件。

那么我能做什么呢?每周申请更多配额?

预先感谢您的帮助!

    标签: google-oauth youtube-data-api


    【解决方案1】:

    这是桌面应用程序的一个已知问题。您需要首先确保您的客户端 ID 和客户端密码已内置到您的应用程序中,并且已编译到其中。是的,您的应用程序可以被反编译以获取客户端 ID 和客户端秘密,但这需要黑客的另一半做更多的工作。即使将其编译到应用程序中,您也可以对其进行散列或加密。

    基本上你不应该在安装时将它作为明文包含在你的应用程序中。

    您可以交替将此客户端 ID 和客户端密码存储在您的服务器上。然后在您的应用程序中有一些方法可以从服务器请求客户端 ID 和客户端秘密。然后您可以通过应用程序许可证密钥将其锁定。您还可以限制每个许可证密钥对客户端 ID 的请求数量,以确保一个用户不会占用您的所有配额。

    我过去曾为客户做过这两件事。你真的必须要有创意。

    【讨论】:

    • 谢谢,非常感谢您的回答。客户端 id 和秘密在二进制中编译,重新编码,混淆等。但正如我所说的使用提琴手,例如你很快就会得到它。唯一的可能性是服务器应用程序生成刷新令牌并将其交给客户端是的。但这是一个开源爱好项目,我不认为我会为此设置另一个网络应用程序。谢谢!
    • 几年前,我确实向 Google Oauth 团队的某个人提出了这个问题,他们真的无法给我任何更好的建议。如果您设置了一个网络应用程序,那么您可以将其锁定到您自己的服务器重定向 uri,这将不再是问题。对于已安装的应用程序,您会卡住,因为重定向 uri 基本上是请求来自的位置,因此真的没有办法将其锁定。
    • 我今天稍微深入研究了一下,API 凭证用于获取刷新令牌以及获取访问令牌。因此,要秘密保存 API 凭据,我必须在自己的服务器上生成访问令牌,并从我的应用程序中向服务器询问每个访问令牌。所以我还需要从应用程序用户到服务器的连接,比如帐户系统,确保安全通信等。我同意,你需要有创造力。 :)
    【解决方案2】:

    在原生应用程序中处理 OAuth2/OIDC 确实是一个难题。

    相关规格为:

    值得注意的是,规范要求提供商(即 Google)在使用原生应用程序时不要将客户端机密视为机密。还有其他攻击媒介,例如在操作系统中拦截 OAuth2 响应。

    上次我检查时,供应商之间的支持非常薄弱,但实际上我能找到 Google 声称提供遵循 RFC 的a native app OAuth2 implementation。我建议仔细检查这在多大程度上是正确的,以及哪些库和代码示例实际使用了这个流程。

    • 一般来说,对于一个开源爱好项目,我会强烈调查要求每个用户向提供商请求一个适当范围的开发人员 API 密钥并在您的应用程序中提供该密钥,这意味着不会有共享的秘密被盗。 (不确定用户通过 Google 获得开发者密钥有多容易,但使用 GitHub 很容易。)
    • 您可以尝试的其他事情(频繁轮换凭据、跨发行版更改凭据等)可能不会是您认为自己烦恼的事情。
    • 我希望您能为减少 YouTube 垃圾邮件做出贡献,并尽快撤销您怀疑泄露的所有凭据! :)

    【讨论】:

      猜你喜欢
      • 2019-12-19
      • 2010-09-18
      • 2011-06-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多