There is no way to store information in a way that it can be able to be decrypted, without it being also insecure in some fashion. This is one of the big problems with storing SSL private keys -- you either have to have someone key in the passphrase when it starts up, leave it unlocked, or encode the password as plain text (or some way to get it decrypted, and the instructions to decrypt it).

Your best bet is to have the process run as a daemon, and enter in the information when it starts up. It can still be recovered if someone can force it to core dump, and then they can go through it for the information, but it's about as secure as you're going to get. (well, you could store in memory encrypted, with the information to decode it, but again, someone who really wants the information could get to it.)

As with anything, all you can do is slow someone down who might gain access -- unlink the script after you've started the process, etc, but it's never going to be perfect. You'll have to decide for yourself how the risks associated with the task compare to the benefits that you might get from it.

Oh ... and it is possible to hide processes from showing up in the process list (so it's harder for people to find and kill it, especially if it deletes itself when running, so there's no file to associated it with), but then we're getting into the process of how to hide worms and rootkits.

Security of the kind you want depends on trusting the root user. Run your script from a machine that only you control. Don't run it without an encrypted connection.

Source obfuscation or encryption is not useful. Anybody who can read or run the script can read the key. Unix file system permissions are a better way to prevent unauthorized access to your keys.

You may not be da Donald, but that's no protection.

Security of the kind you want depends on trusting the root user. Run your script from a machine that only you control.

Certainly, I should have mentioned this from the start. I'm the one and only user of the machine in question (and naturally have root access).

the lowliest monk

This problem seems to me the same wherever secure automation is required. The solution that I am employing in an automated SFTP application is as follows (substitute PGP for SFTP to apply to your problem):

• decrypt an encrypted key and load it into memory using an agent. In my case the agent is ssh-agent, and in yours it might be gpg-agent. This step requires the pass phrase to be typed in at the console. The fact that it does NOT reside on disk anywhere is what stregthens the security of this approach, so even root couldn't easily get your PIN.
• use the keychain script (http://www.gentoo.org/proj/en/keychain/index.xml) to allow a batch process to access the key in memory. The process needs a PID and socket name to access the key, and keychain makes this available to processes that have no tty.

I have had success with this approach in both cygwin and Solaris environments. I think you might research an approach that uses GPG to encrypt your bank PIN, and Perl modules for GPG integration. The pass phrase that I referred to above is for the GPG key, not your bank PIN, so even if someone watched you type it in, they still wouldn't have your PIN.

This just seemed related to the problem I'm working on, but I haven't tried automating GPG, so I don't know if it would actually work. A key issue in my application comes from SarbOx and how to protect things from a compromised superuser account.

PCS

Okay, after re-reading my post I can see that in a GPG scenario root could quite easily get the PIN simply by running a different script to access the gpg-agent. In my SFTP scenario, the thing I am protecting is the ssh key, and that's a lot easier to do.

Perhaps you can keep your PIN in a database with access controls in place. But a compromised root account can make protecting something on disk extremely difficult.

I will be watchiing this thread with great interest.

Update: removed extraneous punctuation

PCS

Apart from any technical consideration, this seems more a philosophical one. All modern crypto systems, however strong they may be, make the basic assumption that you only know the secret information that lets the sesame open. Even without knowing them, a powerful and lengthy attack could eventually lead to the desired secret.

So, the issue is that you have to assess the risk and play with it. It's like you wrote the PIN inside your agenda to be sure not to forget it: how secure is your agenda? Maybe you write all your passwords inside it, and keep it inside the most secure bank - do you really do this?

If you really want to keep your secret inside the computer more than in your head, you should ask yourself how secure your computer is and how a potential attacker could gain access to it; so, it seems more a "contour problem" to me, that is: how much is your computer exposed?

Moreover, you should really assess whether a potential attacker could be really interested in losing time to find the secret: if you keep $1000 average dollars in your bank account, is a $1000 (add zeroes at will) attack worth the trouble for h(er|im)? The level of security should be such that an attack would be too expensive with respect the reward; unluckly, this has little to do with Perl, I fear, even if it might help :P

As a side note, you could afford some kind of compromise keeping the secret (a GPG secret key, for example) always with you with an USB disk, and feed it to a daemon when it's needed. If you spend some time near your server, you could plug the disk when you arrive and unplug it when you go away, keeping it with you all the time or at least keeping it separate from the server. This would make it necessary to set up a physical attack to your premises to have access to the USB disk. Then, you could have some script in the cron table that regularly checks for the presence of the key and does its scraping work; just be sure that the secret remains in memory as little time as possible and does not get swapped on disk!

Bye, Flavio.

bank of america, seems to use a static field to login ... should be fairly easy for the less scrupulous people to break in as well, since all they have to do is get into your machine, and check your browsers auto-complete data.

Actually, they don't cache the password, even though it's static. I was just examining the JavaScript on the page trying to work this one out. I checked my saved form fields in firefox, and they do save my user id in full, but that's all. I haven't looked at it in detail, but my guess is they generate the password field that is submitted using JS and then that doesn't get cached because the browser doesn't "see" it. Though, this is only a guess (I only spent 5 minutes browsing code and didn't go as far as to grab the JS source.

B of A has a very neat online banking UI. Being in this area a bit myself, I'm continually impressed as to how well it performs across several browsers / platforms.

cLive ;-)

The vast majority of security breaches are from human engineering (obtaining the "I lost my password" info, or finding a password someone wrote down, or so on), not actual hacking. Keep your virus software up to date, don't network your bank computer to any other computer with internet access, and don't write down your password or allow anyone access to your bank computer.

I have made a significant update to my original post.