On Friday 11 September 2009 08:15:01 am Rodrigo B. 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.