From: David Masover Date: 2009-09-12T01:01:24+09:00 Subject: Re: Password on code - what's the best way to obfuscate it? On Friday 11 September 2009 08:15:01 am Rodrigo Bermejo wrote: > I've been in the need to crate applications which require to make use of > another program which requires authentication. As everyone who has > tried to solve this problem with a script lang (no compiled, what would > be the best term /?), a security concern comes in play. > > Where in hell should I put the password /? Probably the same place you'd put it in a complied language. Consider: int main() { char * a = "one two three"; a = "four five six"; return 0; } Compile that, even strip the result, then run strings on it. I get this: /lib64/ld-linux-x86-64.so.2 __gmon_start__ libc.so.6 __libc_start_main GLIBC_2.2.5 fff. fffff. -# l$ L t$(L |$0H one two three four five six If you were "hiding" passwords in C/C++ source, I hope that makes the point clearly that they aren't "hidden" at all. Indeed, it's the same problem of any DRM scheme -- if you're giving your program to a user, and the program has a password or key embedded in it, the user can get that key. To answer your question properly, I have to ask: Who are you trying to hide this password from? If you're actually going to distribute it to end-users who you _don't_ want to have the key, read the above until it sinks in -- you're _not_ going to be able to obfuscate it to where a user can't figure it out. If this is a problem, you'll have to get more specific -- it's possible there's a way to make it more secure, but it's not going to involve obfuscation. If it's something else, it really depends what you're doing. For example, if your users have that password, but you just don't want it stored in plain text, you might look at interfacing with whatever their local "keychain" might be -- in OS X, this is Keychain. On Linux, this could be KWallet, or it could be gnome-keyring. On Windows, there's something built in that encrypts things using, I believe, the user's login password. If this is a web service, and you just don't want that password in the repository -- understandable, as you might share that code with others at some point -- separate it out, put it in a config file, make sure that config file isn't in version control and isn't world-readable, but is somewhere the app can get at. For example, if it's your MySQL password, you could just put it in ~/.my.cnf and parse that -- or, what I used to do, parse that in a deploy script, and use it to generate database.yml for Rails. Oh, and completely unrelated, but your sig: > rm -rf /usr/bin/rm That's better written as: rm -f `which rm` And it works just fine. Indeed, if you run "rm -rf /", it has no problems deleting every file on the system, including rm itself and the shell. This is because in Unix, a file isn't removed until its last reference is gone -- that means all filenames (each file can have multiple names, they're called hardlinks), and all open handles (any program that has the file actually open for reading/writing). The 'rm' command just removes a link (name) -- this usually results in a file being deleted, but if a program has it open, the file will still exist until the program closes it. So, rm can rm itself (removing the link), so it looks like rm has been deleted. Then, when rm exits, the last link to rm is gone, and the kernel cleans up the file. And yes, I did play with this -- installed a minimal Linux in a vm, and did "rm -rf /" as root, just to see if it would work. It did -- I think the only things left were mountpoints.