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?
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".
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.
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.
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).
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.
