There appear to be several modules related to KeePass on CPAN (I saw at least App::KeePass2, File::KeePass, and File::KeePass::Agent, when I did a quick search)-could you perhaps interface your script with it? Other than that, there are Crypt:* modules that you could perhaps use to encrypt your password files, and have the program decrypt only what it needs when it needs it (or perhaps on startup). Provide the decryption key at startup, decrypt what you need into memory, and run? Just a thought.

Hope that helps.

I've done the groundwork for using the KeePassRest extension from Perl (see here - it's a plugin that provides a local REST API listener port), but I haven't had the chance to do a writeup yet or to put the stuff into a module. But if you're already using KeePass, it seems like the best way to manage passwords - the local listener starts up after you've started KeePass by entering your normal password by hand, and can retrieve username/password combinations as needed, which you then pass to WWW::Mechanize. Your scripts don't need to contain any usernames or passwords or even decryption keys.

I really need to finish that writeup.

There is no one size fits all answer. In general you have the choices of carefully protected plaintext storage in a secure location (ideal for fully automated processes) or encrypted data protected with a passphrase you enter when you login interactively.

In a fully automated environment, your system needs all info sufficient to access the plain text so if the computer is compromised the system has enough information to access the plain text no matter what you do.

On the other hand for interactive workloads, you can use AES (see Crypt::OpenSSL::AES) to encrypt the passwords with a passphrase you enter.

You might also consider measures outside your application and use full disk encryption.

In this case my scripts are fully automated and need to run without any manual input. The KeePass modules mentioned above seem to still require you to store your master password in plaintext to access the database. To me, that seems less secure than only storing the specific passwords I need in plain text.

Yeah. For fully automated environments, plain text with appropriate controls there, is the best you are going to be able to do. Your best encryption is going to be something like full disk or partition encryption which requires you to enter a password at boot or mount time.

Finally got around to writing WWW::KeePassRest to solve this problem. And also wrote an article about the writing of the module, background stuff, etc.

To make a long story short, if you set things up in your KeePass database and install the KeePassRest plugin, you can do this:

   use LWP;
   use WWW::KeePassRest;
   use strict;
 
   my $url = 'http://somesite.com/aa/bb/cc.html';
   my $browser = LWP::UserAgent->new('Mozilla');
   $browser->credentials("somesite.com:80", "Realm",
      WWW:::KeePassRest->get_by_title('Some site credentials',
                                      'UserName', 'Password'));
   my $response=$browser->get($url);
[download]

Is this a Windows only solution?

From https://www.smartftp.com/keepassrest:

System Requirements

• KeePass 2.32 or higher
• Windows 7 SP1, 2008 R2, 8, 8.1, 10
• Microsoft .NET Framework version 4.5 or higher

So that looks very much like a "yes" to me.

The similar KeePassHttp plugin doesn't have that restrictive license, so I wrote a module WWW::KeePassHttp to interface with it. See my other post Announcing WWW::KeePassHttp v0.01 for more details, in case it's useful to you.

It would seem that you have correctly identified the various pros and cons associated with password storage anytime you must work with a non-interactive environment. The only thought I can offer would be to possibly mitigate the exposure by having secondary accounts on the relevant websites with the minimum access you need to accomplish your goal.

At the very least, be sure than none of the passwords you must use for this are used for any thing else (but I suspect you already follow that practice.) On the plus side, It might be that these can have a high degree of randomness if you never (or rarely) enter them by hand.

Mechanize has no idea where the values it sends come-from.   You’re right that storing passwords in plain-text form represents a potential weakness ... but if you encrypt them, well, you have to store the encryption key somewhere, too.   So, an API to KeePass would probably be the best bet here, and this will have nothing directly to do with Mechanize.

But then you have to store the KeePass DB password in plain text somewhere, right?