Re: Protecting passwords in source

If you encrypted the password, you'd presumably then have to have a password to decrypt it and you're right back where you started from. Start by making the source only readable by the narrowest possible amount of people (possibly by making it setuid, but make sure you've read perldoc perlsec and trim the privileged code down to the bare minimum to get the job done). You could also use a source filter, but that also has limitations (see perldoc -q "hide the source").

Depending on the application you might be able to use some other means of getting the password to your application (for instance running it under ssh-agent) or running as a different user (sudo or the like). More details about what you need the password for might help people steer you towards a more applicable solution.

--
We're looking for people in ATL

Comment on Re: Protecting passwords in source Select or Download Code

Replies are listed 'Best First'.
Re^2: Protecting passwords in source by pg (Canon) on Jul 20, 2005 at 01:45 UTC
"If you encrypted the password, you'd presumably then have to have a password to decrypt it and you're right back where you started from. Not neccessary. An alternative, actually much better, is to compare the crypted password, not to decrypt it. Decrypt could even be impossible. (You got two instances of crypted passwords to compare: 1) at the time when the password is created, you crypt it and store it in the system; 2) when someone try to login or whatever, he/she provides the password, you crypt it in the same way as in step 1, and compare the crypted version with what is stored in the system.)	[reply]
Re^3: Protecting passwords in source by jhourcle (Prior) on Jul 20, 2005 at 05:21 UTC
Decrypting may be impossible, but you don't have to decrypt it -- you just have to find something that creates the same string when encrypted using the same routines through brute force. Computer security is a bit of a misnomer -- it's never secure in an absolute sense, it just has an acceptable risk, normally by using mechanisms that will attempt to reduce a person's chance of managing to gain access without permission before the information loses its value down to an acceptable level. But now, we get to the real question -- why is the password in the file? All of these suggestions to store the password using a one way encryption are great, if the script is authenticating a user giving the password. If the script is a client, and needs the password to connect to another service, those suggestions aren't useful. The original poster might be interested in the thread Quest: a bulletproof-secure, automated scraper, which had a few suggestions on better protecting a password, but they all just slow down someone trying to get the password, and they're not likely to have a whole lot of help on a system where you don't trust people with root access, who could just change the code to write the unencypted/unobfuscated password before it makes use of it.	[reply]
Re^3: Protecting passwords in source by Fletch (Bishop) on Jul 20, 2005 at 13:25 UTC
What I took the OP to be asking was how to hide a password which they need to provide to something else (e.g. to a database or an Expect driven `ssh` session). In that case having a hashed password does you no good, which is why I didn't mention it (the original question was too vague to call it either way). -- We're looking for people in ATL	[reply]