Is it unsecure to use a password on the command line to run a MySQL script on Windows?

I suppose it depends on your specific environment and just how paranoid you want to be.

If you're sitting alone in your home/apartment/cave and there's no one else/no one you can see/no other humans there, then you're probably/maybe/might not be OK.

On the other hand, if you're at work/coffee shop/crowded subway platform where you can't control/limit/know who's looking over your shoulder you might not be OK/all right/alone.

And if you put your password in a script, all bets are off/off/off.

Just remember - don't go upstairs/answer the phone/talk to strangers.

Share and enjoy.

posted over 4 years ago

CC BY-SA 4.0

BobJarvis‭

101 reputation 0 3 8 3

As with every other security-related question, the first step toward answering this is that you'll need to answer for yourself: what are you trying to protect against?

Security isn't a binary quantity, it's a continuum; or rather, a set of continuums, one for each potential threat. You aren't either secure or not, even against something in particular; rather, you're secure against a given amount of effort in a particular attack. The trick to security (in both the physical world and in computer software) is to decide how much effort you need to protect against for each particular attack, as well as which attacks are simply out of scope. For an example of the latter, it's kind of hard for any software to protect against a denial of service attack caused by someone attaching explosives to the computer and detonating them, so most, even security-oriented, software doesn't try to protect against that threat.

You mention that

Given that its possible to go back through command line history on a Linux machine, I can see how that could be a security problem.

However, that's not the only reason why passing a password on the command line is potentially insecure.

On *nix, anyone who can log on to the system (or more generally, run processes on it) can inspect the system state and determine what processes are running, and the command-line arguments for each. (For example, using something like ps auxw, or programmatically through procfs.) Unlike accessing someone's saved command-line history, this typically requires no special privileges at all. Processes can rummage around and make it more difficult to determine the command line parameters passed once they are running, but there's still a window of opportunity when the password is available in clear text to anyone for the taking. It's probably possible to tighten things down, up to and including using containerization or jails, but most people who pass a password on the command line probably aren't doing that.

It looks like you can access similar command state in a variety of ways on Windows, including wmic process get processid,commandline which doesn't require any special tools.

Remember that both modern Windows, and (as far as I know) every *nix there has ever been, are, at their core, multi-user systems. (They do vary in how well, and to what extent, this is exposed to users.) Especially in a shared environment, any reasonable threat model therefore must include an adversary that is able to execute (at least unprivileged) processes on the machine. Once you grant an attacker that ability, there's a good chance that they will be able to inspect process state and derive the command lines that were used to invoke them.

At which point a password passed as a command line parameter is potentially compromised.

That's more of why it's potentially insecure to pass a password as a command line parameter, than simply the fact that typical *nix shells tend to save the command history in their default-distributed configuration.

posted over 4 years ago

CC BY-SA 4.0

4y ago

Canina‭

1489 reputation 2 23 150 31