I need to provide some passwords, API keys and similar sensitive data in my code. What are best practices in that regard? Hard-coded? SQlite? Some cryptographic framework?
Use the Mac OS X Keychain:
Update:
If your goal is to conceal information from your end users, then I'm not aware of a built-in way to do this.
Hard-coding is a start, but a user with a debugger can read the string out of your binary. To combat this, I've heard of developers that store the data as many separate strings and then combine them at the last minute. YMMV
You can not secure them. You can only try to hide them so it's not too obvious. Security by obscurity that is. But I don't think there is a way to keep someone who is willing to get his hands dirty from finding them.
You can use anyone of the posix compliant C cytographic libraries but as noted above anyone with the skills to crack your code can defeat the encryption by finding the key.
There are a few tricks you can use to slowdown a cracker: (1) Use gibberish names for classes, methods and variables to obscure the code handling encryption e.g. -(void) qwert asdf:(NSString *) lkj; (2) Put in duplicate routines and branches that don't actually do anything. (3) Hide data in unexpected place such as within images.
Like the others said, you can't both secure an API key and use it in your app. However, you can do simple obfuscation relatively easy and if the payoff to the cracker is low then you may not get burned.
One simple technique is to break your API key into several sub-strings. Make sure you put them in your code in some random order. For instance, if your API key is "12345678901234567890" you might break it up into 5 substrings like this:
static char *part1 = "12345";
static char *part5 = "7890";
static char *part3 = "890123";
static char *part2 = "67";
static char *part4 = "456";
If you run /usr/bin/strings on the resulting binary then you should not see the API in order. Instead you'll see the API substrings in the order listed in your C file. With 5 substrings like this, that is 5*4*3*2*1=120 permutations. If you break it into 13 substrings you're looking at over 6 billion permutations.
However, that won't stop someone who knows what they're doing from getting your API key if they want it. Eventually you'll have to combine the strings together and pass it to one of your methods, at which point a cracker could use a debugger to set a breakpoint and inspect memory.
To add to the direct answers: It's all for naught if you don't use a secure method of transport, such as TLS or SSH. If you're sending the reconstituted API key in clear text, it's not hard for someone to use something like Wireshark or tcpdump (or, a bit more difficultly, a customized router) to capture it after it leaves your app.
If whatever API you're using doesn't offer a method of encrypted access, then there's nothing you can do about that (besides ask for one), but if it does, then you should use it.