防止滥用libspotify密钥 [英] Preventing misuse of libspotify key

问题描述

libspotify的使用条款规定应以安全方式存储密钥.存储我发现的密钥的唯一建议是编译应用程序并分发二进制文件.除了很难理解安全性之外，我很难理解这一点，因为可以使用调试器轻松检索密钥.

The terms of use for libspotify state that the key should be stored in a secure manner. The only recommendation for storing the key that I've found is compiling your application and distributing the binary. I have a hard time seeing this as anything else than security by obscurity since the key is easily retrievable using a debugger.

这真的是Spotify建议的方法吗?如果我仅编译包含密钥的文件并将应用程序的其余部分作为开​​源分发，该怎么办?

Is this really the approach Spotify suggests? What about if I only compile the file containing the key and distribute the rest of my application as open source?

我想我的问题的实质是:在不要求每个用户都获得自己的密钥的情况下，如何避免违反ToS?

I guess the essence of my question is this: how do I avoid breaching the ToS without requiring every user to obtain their own key?

推荐答案

逻辑是这样的(我为Spotify工作):要求我们的开发人员跳过一堆箍只是为了将API密钥放入二进制文件中会值得的-开发人员将因此而被关闭，所有人都会感到不高兴.

The logic is this (I work for Spotify): requiring our developers to jump through a bunch of hoops just to get their API key into their binary isn't going to be worth it - developers will be turned off by it and everyone will be unhappy.

但是，我们不希望散布密钥，这仅仅是因为如果每个人都在使用一个密钥，我们将无法可靠地跟踪它，并且如果该密钥最终被用于恶意的东西并且我们将其杀死，很多应用程序会突然被破坏.

However, we don't want keys to be spread around, simply because if everyone is using one key, we can't track it reliably and if that key ends up being used for something malicious and we kill it, lots of applications will suddenly be broken.

要想模拟可怕的汽车，可以想象一下API密钥是一些有价值的物品，而您的应用程序就是汽车.如果您将该物品放在汽车座椅上(即以纯文本形式显示API密钥)，实际上是在邀请某人闯入并窃取它(即在自己的应用程序中使用您的密钥).如果将它放在杂物箱中(将其编译为二进制文件)，如果有人闯入您的汽车(拆解您的应用程序)是因为他们知道该物品在杂物箱中，那么无论如何这都是很多游戏.

To force in a terrible car analogy, imagine the API key is some valuable item and your application is a car. If you leave the item on the car's seat (i.e., having your API key in plain text), you're practically inviting someone to break in and steal it (i.e., use your key in their own app). If you put it in the glove box (compile it into your binary), if someone breaks in to your car (disassembles your app) because they know the item is in the glovebox, it's pretty much game over anyway.

简而言之:编译密钥绝对是通过隐蔽实现的安全性，但是当直接从我们这里获取密钥相当琐碎时，我们认为足以阻止人们随意重用其他应用程序的API密钥.

In short: Compiling in the key is absolutely security through obscurity, but we feel it's enough to dissuade people from casually reusing other applications' API keys when it's fairly trivial to get one from us directly.

我想我的问题的实质是:如何在不要求每个用户都获得自己的密钥的情况下避免违反ToS?

I guess the essence of my question is this: how do I avoid breaching the ToS without requiring every user to obtain their own key?

如果您以二进制形式分发应用程序，则将其编译就可以了.如果您以源代码形式分发它，则您实际上不能包含该密钥.

If you're distributing your application in binary form, compiling it in is just fine. If you're distributing it in source form, you can't really include the key.

这篇关于防止滥用libspotify密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！