Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

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

+5
−0

Its possible to execute a MySQL file from the command line like so,

mysql -u USER   -pPASSWORD < FILENAME

which triggers a warning,

mysql: [Warning] Using a password on the command line interface can be insecure.

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 the Windows command line doesn't give one that ability, so would it still be a potential problem there?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (1 comment)

2 answers

+13
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+0
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »