Re^4: Keeping a password safe.

[Steve_BZ]

Hi Flexvault,

Yes that is the problem.

I have two support and maintenance problems.

1. How to support users remotely and interactively on Linux (eg remote desktop and I'm experimenting with Teamviewer. Although it seems to have some security issues (eg the free version seems to be routed via a third-parties server) these are transitory, because you are not *always* connected.
2. How to provide general updates and patches for local Perl installations and this is where I am asking the questions. I am planning that the application will, according to some schedule or frequency, log onto the remote, secure, website and download the appropriate patches. However, I don't want the password to be freely available to casual users (actually, I have the same problem with the DSN password for my Firebird database).

So clearly using a file is better and more maintainable than using plain text in the code. I was planning on using a single user and password, but maybe I should use a separate user for each remote machine, then I could change the password each time it is used. The user would only then have a password for the next logon, which would expire after one logon.

Regards

Steve

[flexvault]

Hi Steve,

Just an idea!

You have a secure server, and you want clients to get a set of instructions to run on their machine. I assume you control the server and will write the perl script to get the instructions from the server. (Correct so far?)

So think about this.

• Setup a unique user on your server for each client. Forget about securing the password, but use a ftp like pure-ftpd that you can chain-root the unique user.
• Generate a unique public/private key for each client.(openssl or gnu)
• Encrypt the client's file with the public key.
• Client get the file via ftp using your Perl script.
• If the file is new, the script decrypts the file using the private key and then your script runs the unique commands for the user machine(s).

This whole process can be automated using Perl on both sides. (Note: You can set this up so your users on the server aren't real(can't login). I did something similiar for an AIX server using SendMail. I set up 'adduser/deluser' scripts to generate/delete the pseudo user. The only service the user could do was send/pop email.)

You control the access on the server, so if you have a problem with a user, just change their password until it gets resolved.

I think this could be very secure and still keeps you in charge.

Good Luck...Ed

[Steve_BZ]

Hi Ed,

Thanks for this. It looks very good, but my security knowledge is not really up to processing it. I need to educate myself a bit more before I can understand it.

Regards

Steve