Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Applies to windows clients like Vista, 7, 8 What are the security consideration when running a tool that has a passwort parameter from a URL in keepass.

Is it completely moronic to do so or is it "safe enough" if your machine is reasonably secure (up to date virusscanner with trojan detection etc, local firewall, encrypted hdd).

Reason is, i would like to keep credentials for any sort of system in keepass and open the connection by running the URL so i could connec to for example to a LDAP directory with ldapadmin.exe, SSH via Putty, WinSCP with an addon for it and also Windows Remotedesktop connections via a special command line tool.

I am however weary and would like to be able to make a case against security conscious coworkers or IT security staff.

So in sum: how secure or unsecure is it to run windows tools from KeePass passing the password as a command line parameter. Autotype is often tedious and if it really really is safer i do doubt as it is something passing the windows event qeue and thus potentially easier to grab.

Thanks for your time spent on elaborating a reply :-).

share|improve this question

Let's consider worst case: locally used passwords in plain on your system.

Why worst case?

  • Command line parameters may be logged (locally).
  • The application you are using may cache / store the passwords.

(I may be missing more points here)

Most generic malware won't be looking for passwords on your system, so you don't really need to worry about it.

What you need to consider:

  1. Physical Access - Unless you have full disk encryption or store the scripts in encrypted format / containers, anyone with physical access to the machine can get their hands on it (after turning it off). If using encryption, it now falls to the weakest link, that is the credentials for the user account on the machine.
  2. Targeted malware / machine compromise - In case of a pentest or network-breach (where your machine is compromised), you have made it easier for the adversary to connect to more machines on the network, depending on the access and privileges that your accounts grant them.
  3. Logging - If the command line parameters of the tools that you run are logged (on remote server), and the log server is compromised first, you have provided a free pass again in this case. This, however is a shortcoming of the security of the log server, but another way in which passwords in plain on your machine can be problematic.

In short, you are sacrificing a bit of security for some convenience here.

Depending on how much IT cares about security, they may or may not be OK with the idea.

If you eliminate worst case conditions, the only concern (I can think of) is logging.

share|improve this answer
thanks for the reply. – Dominique Vocat Jan 14 '14 at 12:50
as for 1: encrypted disk, all protocols encrypted. as for 2: we do not connect with the regular user to the systems so you need the credentials or need to run a brute force attack to take advantage of the firewall rules. 3: command line parameters do not reach the opposite system. – Dominique Vocat Jan 14 '14 at 12:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.