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.