防止滥用 libspotify 密钥

Posted 2023-04-15

【中文标题】防止滥用 libspotify 密钥

【英文标题】：Preventing misuse of libspotify key

【发布时间】：2013-03-30 21:04:39

【问题描述】：

libspotify 的使用条款规定密钥应以安全的方式存储。存储我发现的密钥的唯一建议是编译您的应用程序并分发二进制文件。我很难将其视为默默无闻的安全性之外的其他任何东西，因为使用调试器可以轻松检索密钥。

这真的是 Spotify 建议的方法吗？如果我只编译包含密钥的文件并将我的应用程序的其余部分作为开​​源分发呢？

我想我的问题的本质是：如何在不要求每个用户获取自己的密钥的情况下避免违反 ToS？

【问题讨论】：

这个问题似乎是题外话，因为它与 spotify 的服务条款有关。只有关于 spotify api 的问题才是主题。

【参考方案1】：

逻辑是这样的（我为 Spotify 工作）：要求我们的开发人员为了将他们的 API 密钥放入二进制文件而费尽心思，这是不值得的 - 开发人员会被它关闭并且每个人都会不开心。

但是，我们不希望密钥散布在各处，因为如果每个人都使用一个密钥，我们就无法可靠地跟踪它，并且如果该密钥最终被用于恶意活动并且我们将其杀死，那么很多应用程序会突然崩溃。

强行打个可怕的汽车类比，假设 API 密钥是一些有价值的项目，而您的应用程序是一辆汽车。如果您将物品留在汽车座椅上（即，您的 API 密钥为纯文本），您实际上是在邀请某人闯入并窃取它（即，在他们自己的应用程序中使用您的密钥）。如果您将它放入手套箱（将其编译到您的二进制文件中），如果有人闯入您的汽车（拆解您的应用程序）因为他们知道该物品在手套箱中，那么无论如何游戏就结束了。

简而言之：在密钥中编译绝对是安全的，但我们认为这足以劝阻人们不要随意重用其他应用程序的 API 密钥，而直接从我们这里获取一个密钥相当简单。

我想我的问题的本质是：如何在不要求每个用户获取自己的密钥的情况下避免违反 ToS？

如果您以二进制形式分发应用程序，编译它就可以了。如果您以源代码形式分发它，则不能真正包含密钥。

【讨论】：

我明白了，谢谢你的澄清。但是，关于您的最后陈述，我能否请您扩展以下内容：我知道我不允许将密钥本身作为开源分发，但是如何将其（密钥）作为目标代码重新分发，同时仍然保留其余的源开放？当然，我得到的是：我可以将我的应用程序的源代码与我的密钥的编译版本一起放在（例如）公共 GitHub 存储库上吗？我明白到最后，我要为我的钥匙负责。我只是好奇 Spotify 对此的立场。

我将不得不放弃这个问题，因为它就在边缘 - 是的，它已编译但 appkey.o 将是一个非常容易的目标。

可以理解。我不想强迫你说任何可能给你带来麻烦的话。感谢您的帮助，无论如何。我将保留我的密钥并暂时分发源代码。