If a password is hard-coded into a variable in source code such as VB, could someone extract this password by looking at the compiled executable code?
If so, what can be done to avoid this?
+7
A:
Yes, someone could.
Nothing can be done to avoid it. Obfuscation will make it slightly harder.
In the worst case, if someone didn't understand your obfuscated code, they could run your executable in a debugger and read the password from memory just before you use it.
The solution is, of course, not to hard-code important passwords into your binaries.
Borealid
2010-07-30 04:20:58
If a debugger can look at any variable then how could anyone protect a password used to access a database, for example? Surely any such password would be in memory prior to going to the database?
Craig Johnston
2010-07-30 04:27:45
@Craig: you can have the software ask for password and store it to somewhere. Or in case of typical web application, the password is stored to some configuration file when installing the software. The point is that you can't access the database just by obtaining the software, you need the configuration also.
Juha Syrjälä
2010-07-30 04:35:00
@Craig Johnston: for high-security applications, you need a high-security computer. Any credential the computer has access to is compromised if the machine is physically compromised. That said, for most people having a configuration file readable only by a specific user and running the binary under assumed permissions for the user is considered sufficient.
Borealid
2010-07-30 04:37:55
@borealid: but wouldn't the password be stored in memory after it is read from the config file, and therefore it would be accessible to the debugger?
Craig Johnston
2010-07-30 04:42:35
@Craig Johnston : while the application is running, someone who can hook into it can read its memory. When I say "running the binary under assumed permissions", I mean "launch the binary as another user via a setuid script and then have it drop privileges after reading the config file". Users generally can't just read the memory of arbitrary processes running as other users.
Borealid
2010-07-30 04:46:11
Just to make sure we're clear, the important thing here is that, barring poor use of the setuid bit, if you can't read the configuration file yourself, you also can't make the program read the configuration file for you.
Borealid
2010-07-30 04:50:15
A:
Yes. The password could be found by watching the program execute in a debugger. If you do nothing, it might even be possible to find by searching for text in the binary file.
What can be done? There are anti-debugging techniques like obfuscation or anti-tampering mechanisms that will cause the executable to blow up when debugged. Obfuscation is probably easy to implement. Anti-tampering will be difficult.
Steve Rowe
2010-07-30 04:24:06
Anti-tampering will also never be 100% effective. The attacker could step up to running your code in a virtual machine and blue-pill hooking the password out into the hypervisor; your code would have literally no way to know if that type of attack happened.
Borealid
2010-07-30 04:40:52