Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Keeping a password safe.

by flexvault (Parson)
on Jun 09, 2012 at 14:06 UTC ( #975303=note: print w/ replies, xml ) Need Help??

in reply to Keeping a password safe.


Could you explain further, like 'web https passwords' or 'ssh passwords' or 'telnet passwords' or '. . .'

If you talking about web authorization, then you could use javascript and Perl to encode the password, but still all depends on some physical security to a degree.

And like what was already said, anybody with system administrator access can get to them.

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

Comment on Re: Keeping a password safe.
Re^2: Keeping a password safe.
by Steve_BZ (Hermit) on Jun 10, 2012 at 02:09 UTC

    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.



      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.

      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.


      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.



      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://975303]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (5)
As of 2014-08-22 02:26 GMT
Find Nodes?
    Voting Booth?

    The best computer themed movie is:

    Results (145 votes), past polls