[Melbourne-pm] Obfuscating passwords in configurations
sam at nipl.net
Thu Dec 2 18:13:51 PST 2010
Sam Watkins wrote:
> Ok, I was silly enough to implement some sort of password encryption /
> decryption thing in perl. It uses a 20-byte secret, which shouldn't go in the
> same config file, random salt, sha1, XOR and base64 encoding. I think this
> would deter casual inspection at least, and it would be extremely hard to break
> without the secret... unless I've made some stupid mistake!
Toby Corkindale wrote:
> Well, the script you link 404s when I try to download it..
whoops, sorry about that, fixed now.
> I recommend that people use established crypto libraries when they need
> crypto. It's harder to get this stuff right than you might think..
On the other hand, the people who write / hack the established crypto libraries
make mistakes too (e.g. the Debian openssl / ssh fiasco):
Also, there more 'known exploits' for established crypto libraries than for my
home-brew bogus crypto.. but that might change if anyone looked into it!
> What's to stop an attacker editing your Perl program
> say "The decrypted password is: " . $self->config->password;
Absolutely, in that context it's only an obfuscation, just a little harder to
decode than base64. It's more useful if attackers can't see the key, e.g. to
encrypt web cookies. Alternatively, the key might be stored only in the RAM of
a running process, and the attacker would then have to snoop through memory
hunting for it (or search directly for the decrypted password), or run a
debugger / tracer...
Better to lightly obfuscate the passwords and protect the root account! but to
achieve this it would mean not using Linux I guess; at any one time there may
be several local root exploits, and several remote code execution exploits in
common web services. I guess people should use Plan 9 or OpenBSD if they
actually want to have secure servers. But I'm not an exploit expert, and I use
Debian GNU/Linux for my servers.
More information about the Melbourne-pm