Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^2: Keeping a password safe.

by Steve_BZ (Chaplain)
on Jun 10, 2012 at 02:09 UTC ( #975349=note: print w/replies, xml ) Need Help??

in reply to Re: Keeping a password safe.
in thread Keeping a password safe.

Hi Flexvault,

I have a Perl app to which I wish to supply maintenance and other updates from an FTP site. I want the FTP site to be secure and to use an ftp user name and password to access the site, but I want this to be stored in such a way that the password is secure.



Replies are listed 'Best First'.
Re^3: Keeping a password safe.
by aaron_baugher (Curate) on Jun 10, 2012 at 03:25 UTC

    Here's the problem: there's no such thing as "stored in such a way that the password is secure." If your program can get at the password and use it without need for any manual input, then anyone who gains access to your program can do the same. You can do a certain amount of obfuscation so no one will stumble across the password accidentally, but that's not actual security, and it won't stop a determined invader. You could run the password through six kinds of reversible encryption, chop the result up into individual bytes, and hide each byte into a different spot in a JPEG image in a hidden directory; but if your program knows how to reverse the whole process and get the password, anyone who gains access to your program can do it too.

    The same thing is true of SSH private keys, by the way. They're better because they avoid sending passwords across the network, not because their local storage is any more inherently secure. (SSH keys can be protected by requiring a typed-in passphrase, but presumably you don't want to require human input every time you run this script.)

    So the place to worry about security is not within your application or how it stores its passwords, but in how secure your system is at the network, user, and physical level. If the system is on a network, then network security is necessary to make sure no one can get at your application and private data that way. If there are other users on your system, you have to make sure those users don't have access to your files. If they can't read your password file, it really doesn't matter whether your password is cleartext or obfuscated. At the physical level, if other people use your computer, you may need to take steps to make sure they can't access your program from the console, even by rebooting.

    Take care of those levels of security, and you'll have nothing to worry about. Ignore them, and your passwords won't be secure, no matter how you store them.

    Aaron B.
    Available for small or large Perl jobs; see my home node.

Re^3: Keeping a password safe.
by bitingduck (Chaplain) on Jun 10, 2012 at 02:30 UTC

    Plain old FTP isn't very secure-- it generally sends the authentication in cleartext. If you can set up the server to use SFTP then it will be more secure, and you can also set up ssh key pairs for authentication so that you don't have to send a password when you login- when you ssh, scp, or sftp into the server, the ssh program at your end handles authentication via the keypairs. This is particularly convenient if you want to have a pair of computers talk to each other on a regular basis without human intervention. For an example, I have a web scraper that runs at home and generates database inputs from its scrapings that it uploads to the server on its own a few nights a week. I have a few of my accounts set up with ssh keys, and it's pretty convenient.

    Setting up ssh keypairs isn't hard, but I don't do it often enough to have it at my fingertips-- I look it up every time. Here's an example of how to do it (first hit on google). It then depends on the general security of the machines at either end.

Re^3: Keeping a password safe.
by flexvault (Monsignor) on Jun 10, 2012 at 13:16 UTC


    You already have some good answers, but I get the feeling you are asking specific questions about a bigger problem. I searched on some of your previous posts and came up with this.

    These are my limitations: * It does not need to be synchronous (although it can be). * It is running behind a router or firewall *(this means I probabl +y can't log on to it)... * It should provide a log of activity that can be analysed or uplo +aded to a server later.

    Is this still the problem your working on?

    Thank you

    "Well done is better than well said." - Benjamin Franklin

      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.



        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

        "Well done is better than well said." - Benjamin Franklin

Re^3: Keeping a password safe. (min access)
by tye (Sage) on Jun 13, 2012 at 05:16 UTC

    I think a better step is to minimize the power of the information that needs to be exposed to the client. If the client needs to upload files to the FTP server, then give the client access only to upload files and only the files it should be updating. And make that access only work when exercised from the system where the client is run.

    If your FTP server software doesn't support such fine-grained access control, then have the client upload via some other means. You can configure ssh such that connections using a specific key file only allow very specific actions and only from certain IPs. On my OS, "man authorized_keys" (like gives details.

    If the FTP server can even verify the uploaded files in some way, that may also be worth implementing. You could place restrictions on the naming and size of the files. You could examine the files to verify that they appear to be the correct type of file. Perhaps whoever is providing the files to the client could also provide cryptographic signatures for the files that the FTP server would verify. You could have the server send out an e-mail notice if rejected files get uploaded.

    If you think this client is actually likely to be an attack vector, you could even honey-pot the client such as by giving it an 'access list' that it uploads if it gets updated. But never update this file and have the FTP server e-mail if such an update is received (and the FTP server doesn't actually honor the access list, just to be clear).

    You could also have the FTP server send notifications of any updates to a third location so you can periodically review the pattern of updates for unexpected activity (if anybody will actually continue to bother to do that).


    Also, you should run the client from a relatively secure host. Don't run the client from a shared-hosting service, for example. A better choice is a host that requires one layer of authorization just to get through the firewall (such as a VPN) and that has few logins permitted.

    (Though, I was a bit surprised and disappointed that a recent employer had the VPN using LDAP authentication so somebody getting hold of my corporate username and password could get through both the firewall and into hosts behind the firewall -- though I suspect their motivation was certainty of timely revocation of all access upon termination of employment.)

    I doubt your specific upload access case is serious enough of a security concern for even most of these steps to be warranted. But at least you've got a large list to pick from, if you so choose.

    - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://975349]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2018-02-22 19:32 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (298 votes). Check out past polls.