Slashdot Mirror
Keeping Passwords Embedded In Code Secure?
JPyObjC Dude asks: "When designing any system that requires automated privileged access to databases or services, developers often rely on hard coding (embedding) passwords within the source code. This is obviously a bad practice as the password is then made available to anybody who has access to the source code (eg. software source control). Putting the passwords in configuration files is another practice, but it is still quite insecure as cracking hashed passwords from a text file is a trivial exercise. What do you do to manage your application passwords so that your system can run completely automated and yet make it difficult for hackers to get their hands on this precious information?"
IANRAProgrammer, but...
I believe public-key cryptography could do this. Encode the public key (several kilobits, if you're paranoid)? in the source, and have the program use it to authenticate the secret key given by the user. Publish the source code on YouTube for all the good it will do an adversary, right?
Paleotechnologist and connoisseur of pretty shiny things.
But what do you do when you need to revoke the cert? The problem is that they want authentication without the rigor of.. authentication.
I Browse at +4 Flamebait
Open Source Sysadmin
And you know what? That's not secure. But then again, the database it's connecting to should be as firewalled as all get-out, and even if it's NOT firewalled, it should have host-based authentication so that you can only access it with that password from the appropriate machine (your web server). At that point, if someone can hook into your LAN to sniff traffic or spoof things, you're probably in deep trouble anyway - but perhaps you could configure the database server to only accept connections over a VPN of some sort with appropriate authentication certificates.
The World Wide Web is dying. Soon, we shall have only the Internet.
The better practice would be to make raw access a non-issue. Don't give the user account the privileges to accomplish anything that wouldn't be possible with the application itself. If you're using some sort of SQL database, consider limiting the permissions on the account to stored procedures that correspond your application's features.
The problem with this is.... how does the program get the password it needs? If its encrypted with a salt...well, that's one way, so the program would have to do a brute force everytime it wanted to use that password.
There's little point to encrypting a locally stored password, as the decryption technique must be relatively simple to allow the program to access it. The idea is to secure everything around it, including the system that is being connected to. Use host based authentication, firewalls, etc. to reduce the risk.
You type in a normal password, which is then hashed. Then you compare the hashed password to the saved hashed password.
It is kind of moot anyway... if the attacker can get at the file system, they probably can do whatever they want.
-- I ignore anonymous replies to my comments and postings.
For passwords for that program's users, yes it works, but as a stored password to be passed on to another system, like you say, no.
Where I work, we have a product that needs to store a shared encryption key for communications. The interaction with customers, QA, and marketing went like this:
Them: OMG, the password is there in plain text Us: The password is in a file readable by root only, as is the install directory. If you can read it, you already pwn the box Them: OMG, the password is there in plain text Us: The product has to run unattended as root. There's nothing sensible we can do about it. Them: OMG, the password is there in plain textEnd result: we changed the program to encrypt the password using a fixed key. Customers, QA and marketing finally shuts the hell up.