4 ms·
I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seeming
by nknighthb 13y ago
I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seemingly sane person develops an application intended for distribution to the public which contains AWS credentials.
At what point in your development process do you say "I want this application, which will be distributed to unknown persons, to contain the means to control my AWS account."?
- Kudos 13y agoSome people don't realise their apps can be decompiled, it's not a question of sanity.
- nknighthb 13y agoI don't think I've ever encountered that particular illusion in anyone making a living off writing compiled code, only very new developers and non-engineer managers. It's one of the few securityish things that seems to be successfully beaten into everyone's head pretty early on. (And more often than not, they get there all by themselves -- such people usually appear on my radar asking questions showing they've figured out for themselves that it's a bad idea, they just need help turning that knowledge into practice.)
- saurik 13y agoI give talks at development conferences where I mostly blow people's minds by showing how easy it is to pull information out of binaries (both statically and dynamically); there are always tons of questions from the audience afterwards about "but we do X? doesn't that make us safe?", so I have to sit there shooting down a ton of silly ways of obfuscating their data, showing how each one could be defeated, but it "clicks" for everyone that there is no safe way to do this.
- watwut 13y agoI do not think that anyone ever said that. More likely, they just put keys in string to do quick test right now with intention to fix it later. Then they simply forget about it and later never happen.
- rajbala 13y agoI think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not? If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.
- nknighthb 13y agoThe obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform. It's not an "alternative", it's the correct solution. In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps. With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.
- rajbala 13y agoI'm not necessarily disagreeing with you, but it's not always practical and perhaps not even possible. For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app. These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.
- nknighthb 13y agoThose are examples of AWS-like facilities. The embedded keys are not secret credentials that allow people to control your account! If you are embedding your account credentials from Urban Airship or Flurry in your app, you are badly misusing their APIs. They provide facilities for generating certificates/keys for each application.
- 13y ago
- ams6110 13y agoI once worked on a website that had a "sql.asp" page where you could enter any arbitrary SQL into a textarea and submit it. The ONLY security it had was the obscurity of its URL. This was implemented deliberately and with full knowledge of managers and developers. Stuff like this happens....