I would agree, or at least you should be always prompted for the password when that action executes.
-rob.
1 Like
Or that, yes
Password variables are not passed to the script as environment variables.
This is not a “serious vulnerability”. Password variables are not magic - they are treated in a few specific ways to protect them, but you can still use them in actions and thus their results can become visible - if that was not the case they would serve no purpose at all.
Correct. At least, correct in the sense that a password variable is not sent to the environment of the shell script.
You can send it to the text input, for example:
which will also display your password in a window.
The zip command will not read the password from stdin (which is annoying and unusual), so the only two ways to set the password are by typing it manually in a terminal window (not useful for a script), or by including it on the command line with -P which is highly insecure (since arguments can be seen by any process). But that is all you've got, so the solution is basically something like this:
This is a nice theory, but it's impossible even in principle. It's basically a subset of the Halting Problem which is basically that it is impossible to know in general from looking at a program whether it will every finish except by running it until it finishes.
What could Keyboard Maestro do to stop such information leakage? What if you did this:
Should that be disallowed? Or should Keyboard Maestro somehow track that the Regular Variable is now tainted itself and not allow it to be displayed?
Basically, you should treat passwords used within Keyboard Maestro with extreme caution - keep them in a local password variable, read them, uses them, and erase them immediately afterwards. Keyboard Maestro can only protect you so far, after that you need to take ownership of what you are doing with the password in Keyboard Maestro.
1 Like
Since my shell knowledge is more than limited:
- KM will read from the Keychain and create the
Local__myPasswordvariable with the password (that Shell can't read yet) - Then
input=$(cat)will convert that password from the variable that comes fromWith input from variable Local__myPasswordinto the actual password as "text" (in newbie's terms) that shell can read - Then
-P "$input"will use that password in text format (similar to manually typing the password) to compress the encrypted file.
Something like this?
1 Like
Correct.
And by putting the password in plain text in the argument list, it is visible to any process running on your Mac.
But only for that brief moment that's reading the script, right?
Because it's reading the password from the KeyChain, converting it to "text" so the shell can read it (using "cat") and once the script has done its thing, the password is no longer visible, correct?
"Cat" in this case, is a command, right? Online source:
"It can be used to display the content of a file, copy content from one file to another, concatenate the contents of multiple files, display the line number, display $ at the end of the line, etc."
Sure. But that information can easily be logged for example.
“brief moment” for computers doesn't really mean much.
It all depends on the sensitivity of the information and your risk factors as to whether its a reasonable risk or not.
Correct. cat reads the stdin and outputs the same thing, which is then captured and stored in the variable.
1 Like
Question: if I have a macro that reads a password from KeyChain but in order to copy it to clipboard, for example, but I need to type in the admin password for it to do it, will that be safe?
Context: I want to access certain passwords in KeyChain and being able to copy them to the clipboard, but I want it to be secure so no one, even with access to KM can access them. So if I always pick the option to only allow once (the access to the password), is that safe? Or does it also have that problem with any process logging it?
Hope it makes sense?
You can definitely configure the Keychain items to require the password when accessed, and that will be desirable for any password you want kept secure.
It would ensure that the password cannot be read except when you specifically allow it to.
But it would not resolve the issue in this case in that the password will still be visible to any process that wants to see it when the macro is run.
This question was not related to this post now.
I was just wondering if it's safe when Keyboard accesses the KeyChain and requires to type in my admin password in order to get that password.
For example if I have all my website passwords saved in the KeyChain and then I use KM to access them with a shortcut instead of opening KC and all that.
So I would then create a User Prompt that would allow me to type in my admin password and the password for a particular website would be copied to clipboard or it would show it on screen.
Is this safe or should I avoid using KM for any password completely?
It's probably better to start a new topic in that case, but moving along.
If the Keychain entry is configured to require a password when Keyboard Maestro reads it, and if you read it from the Keychain in Keyboard Maestro (which prompts for your authentication), into a Local or Password variable, and then use Insert Text by Typing into a password field, then that should be entirely secure.
If you used Insert Text by Pasting, then the password would go in the clipboard and anything can see it.
If you use a non-Local/Instance/Password variable, then the variable would be written to disk and so anything can see it (by looking at the file directly, or by querying Keyboard Maestro via AppleScript).
If it was not a password field, then other applications with Input Monitoring/Accessibility permissions could see it.