0

I have a script which executes curl many times.

I'd like to enter my password only once (so I don't want curl to ask for it on every execution). I don't want the password to appear in process list or in a file descriptor or something.

#!/bin/bash

read -p "Enter pw:" -s pw

provide_pw() {
    cat << END
"$pw"
END
}

for i in {1..10}; do
    curl -u $(logname):$(provide_pw) "$url"
done

Is this approach secure or is it possible for another user to get my password if I do it this way?

2 Answers2

3

For all the dancing around with read and cat and heredocs, ultimately command substitution will result in $(provide_pw) being replaced by the actual password. It will then be part of the process details.

From man curl, about -u:

On systems where it works, curl will hide the given option argument from process listings.

So, on such systems, and also on Linux systems with hidepid set appropriately, the password will be hidden from other users, but elsewhere, everybody can see the password by looking at the command line of the curl process using ps, top, etc.

If you're willing to read the password, just have curl do it for you:

If you simply specify the user name, curl will prompt for a password.

Also see: How does curl protect a password from appearing in ps output? There is a race condition here: between curl starting and getting around to cleaning the command line, the password will be visible, and if it isn't hidden by other means (like hidepid on Linux), will be visible to everyone during that window.

muru
  • 72,889
  • Thank you very much for your reply! I will look into curl's hide pw capabilities. Letting curl ask for the password is not an option, because in my script it is executed many times and I don't want to type in the password everytime. – EagerToKnowThanksAlot Aug 16 '19 at 05:59
  • 1
    Given the script you have shown us, there is no reason to run curl multiple times. You can run curl once with multiple URLs. – muru Aug 16 '19 at 06:05
  • Good point, the script in my question is a shortened version of my actual script. In my longer version I talk to REST API sending data to a server. Unless curl is capable of sending multiple API calls with one execution I need to invoke curl multiple times, like I stated in my question. – EagerToKnowThanksAlot Aug 16 '19 at 07:07
  • Then use .netrc like Rinzwind suggested. In any case, what you do with curl is irrelevant. The question is is this insecure, and the answer is that it is insecure. – muru Aug 16 '19 at 07:15
1

It's very common to put your password into curl command line arguments. It may not be the most secure way to use a password, but nothing is perfect and in most cases there aren't many or any other options.

Your function to get the password is completely unnecessary though. You can simply do this:

read -rsp "Enter pw: " pw
curl -u "$(logname)":"$pw" "$url"

Note: I've added the -r argument to your read command as it will allow you to read backslash escape characters literally which you will certainly want to be able to do for passwords.

jesse_b
  • 37,005
  • " but nothing is perfect " wanna bet you can do it more secure ? – Rinzwind Aug 14 '19 at 14:10
  • @Rinzwind: I know you can, I just don't think most people care to. In fact my answer says "It may not be the most secure way...". If someone is reading your password from command line arguments on your own machine you have already been owned and the password to some miscellaneous API is the least of your concerns. – jesse_b Aug 14 '19 at 14:13
  • 1
    the OP specifically said "but I don't want it to appear in process list or in a file descriptor or something." - this answer doesn't even attempt to do that. it does exactly what the OP said he didn't want (and presumably already knew how to do, otherwise he wouldn't be saying he didn't want to do it). – cas Aug 14 '19 at 14:56
  • OPs question is literally in the title: "How insecure is it passing a password to curl via cat". – jesse_b Aug 14 '19 at 15:12
  • To which the correct answer is "completely insecure if anyone other than you can run programs on the machine", which is missing from your answer. But there's more to a question than just what's in the title - that's why there's a whole input field that can be formatted in a variety of ways in which to put the full question. – cas Aug 15 '19 at 05:25
  • Thank you all very much for your input! As @cas stated, my whish is to find a reasonably secure solution to my problem. I haven't thought of the read -r option which is helpful and it's good to point out, my subshell approach via $() was useless.

    If anyone does know of a better more secure way, I'm be very curious. :-)

    – EagerToKnowThanksAlot Aug 16 '19 at 06:01