Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

88%

+13 −0

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

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 quant...

posted 3y ago by Canina‭ · edited 3y ago by Canina‭

Answer

#3: Post edited by

Canina‭ · 2020-08-26T17:55:28Z (over 3 years ago)

Copy Link

Raw

Markdown

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 quanty, it's a continuum; or rather, one continuum 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.

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.

#2: Post edited by

Canina‭ · 2020-08-26T16:41:40Z (over 3 years ago)

Copy Link

Raw

Markdown

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?**
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.

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 quanty, it's a continuum; or rather, one continuum 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.

#1: Initial revision by

Canina‭ · 2020-08-26T16:35:47Z (over 3 years ago)

Copy Link

Raw

Markdown

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?**

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.

Communities

Post History