Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

If there is a need for source code to have a password in it, how should this be secured? This is purely an example, but say there is an app that is using an API, and you don't want to expose your API key, yet you need to have it in the source code, because it is used. How do you effectively have a string that the user cannot retrieve yet can be used. Does not seem possible without asking the server for the string.

RE: Why can we still crack snapchat photos in 12 lines of Ruby?

share|improve this question

marked as duplicate by Gilles, Adnan, Xander, Scott Pack, Steve Mar 5 at 17:19

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

As "hakjhkjdhakjhdkja" pointed out in the previous question: What Snapchat promises is impossible to do according to the current state of computer science. There is no such thing as self-destroying information. Whenever they state that it would be impossible to permanently save an image sent over their service, they are lying! –  Philipp Mar 4 at 17:48
Related: security.stackexchange.com/questions/20294/… –  Zar Mar 4 at 18:34
Haha, okay my comment got tuned into a question though I had asked the question already. –  Fogest Mar 4 at 20:10

5 Answers 5

up vote 11 down vote accepted

Short answer: you can't.

You can't never protect a password that you are distributing. You might hide it between some strings and use other operations to "cover" the password but, in the end you will have to put it all together to make your function to operate. And here is where the cracker is going to take it.

There is no easy way to solve this problem and usually it means that you have not chosen the best security scheme or, if you feel it is enough, maybe it means that you just don't need this kind of security.

And if you really, really, really need to do in that way you will have to go with "security by obscurity" after all, the longer it takes to be cracked, the better. You better have some detection system for when this happens.

As an example, consider the gaming industry all these years with their copy protections and so on, if there would have been a way to achieve security within the code itself that would mean the end of "piracy".

share|improve this answer
sooo.. when a developer (like myself) uses an app API key e.g. Google Services in an app, if it is so easily discoverable then it is feasible for another dev to basically use my API key maliciously and get it blocked. Then I would need to get another key - rinse and repeat. Is there something on the server to prevent this? –  Peter Mar 4 at 16:06
If someone takes apart your app and discovers your API key, they can use that API key as they will. You can try to protect this by signing your requests, but the discoverer can (and will) mimic your signing logic as well. It's done every time someone jailbreaks an iPhone. –  John Deters Mar 4 at 18:11
Well, at least in theory you can... kind of. Assuming that the platform is closed, or "trusted" as companies like Microsoft would put it. So you either have some special hardware that simply doesn't let you access data on your own computer unless they allow you to, or you have an operating system (like WinRT) where they control what programs you may install, and there is only a single way of installing software. –  Damon Mar 5 at 0:06

While @kiBytes answer is correct in a practical point of view, I would like to add to add that a recent paper by Amit Sahai suggests a (theoretical) way to build a black box obfuscator that is cryptographically "hard" to reverse. (See here for a wired article about it).

It's not, however, as if you could or even should implement it: so far, it's completely impractical to use on real software and it hasn't been properly vetted yet. It's interesting nonetheless.

share|improve this answer

As @kiBytes says, you simply can't secure a password or key inside source code. I'd add (in case people arrive at this question trying to solve a general concern) that in the example you give (an app using an API), there's no need for the API key to be stored in the app source code.

Typically, the API key is stored on a server you control. To access the API, your app makes a request to the server, which itself makes a request to the API, and then replies to your app with the information it retrieved from the API.

As an aside, ideally the API key isn't stored in source code on the server either, since that's presumably checked into version control and thus potentially insecure.

share|improve this answer

Something I did 20 years ago was to split the key into its individual characters then build a collection of objects that explicitly returned those characters in the correct sequence once the objects were sorted based on another attribute of the classes. With obfuscation, this is pretty tough to crack especially if the correct order of the objects is hard to determine (eg. it changes depending on the application environment).

share|improve this answer
Or you just attach a debugger to the code when running and see the generated password when it gets used. –  Steve Mar 4 at 17:25
This is security through obscurity. Anyone determined could have found out about your scheme. And now that you published it it has become completely unusable, because a cracker knows what to search for. –  Philipp Mar 4 at 17:43

Note that standard practice for storing passwords ANYWHERE is to never store the password itself. Instead, store the result of a cryptographic hash (a "trap-door", or one-way, cypher) of the password. When the user enters a password, hash it the same way and compare the encrypted versions.

In this case, as Brendan points out, the question is one of authenticating the client rather than the server. This is more difficult since the client's code can theoretically be reverse-engineered. The best suggestion I can offer is to make the client itself act as the password in a challenge-response system -- have the host send a request that a cryptographic checksum be computed of a(n apparently) randomly selected subset of the program, which the host will check against a result precomputed against the same version of the client code.

This does not guard against piracy, per se. It does guard against access by clients other than the approved one. I don't know whether that addresses your needs or not.

share|improve this answer
This isn't relevant to the kind of passwords they're talking about (keys distributed with the application, not coming from users). –  Brendan Long Mar 4 at 17:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.