Is curl -u username:password secure?
If not, can you give a brief explanation of how someone could obtain your password?
35 Answers
It is unsafe, because cURL defaults to basic authentication where HTTP protocol sends your password in clear text. When you specify the username:password string, it gets converted to a BASE64 string in the HTTP header:
GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=Anyone able to intercept your HTTP traffic (your provider, anyone accessing the same wireless AP as you etc) will be able to recover the password by simply using an online BASE64 converter.
HTTPS protocol will make things better by establishing an encrypted connection before this header is sent, preventing the password from being revealed. However, this only applies if the user pays attention when asked to confirm unknown certificates, authorize security exceptions and so on.
Note that command arguments might be available for other users on the same machine to see, e.g. ps -ef, /proc filesystem, in you bash history, and in your terminal log (thanks for @Lambert's comment noting this). cURL on some platforms attempts to hide the password so for example with ps -ef you are likely to see blank space instead of a password. However, instead of passing the password as a command line argument, having cURL directly prompt for a password is better, as discussed on the cURL faq.
It is not secure. Command line parameters are visible to all users.
7This could be done in a more safer way by using --netrc-file parameter.
- Create a file with 600 permission
For eg: vi /root/my-file
machine example.com
login USERNAME
password PASSWORD
Save and Close the file
- Use the below to access the URL with Username and Password.
curl --netrc-file /root/my-file
- Done
It is insecure when using HTTP scheme. To make it secure, you should use HTTPS.
To hide password from appearing in command history, only provide user name. Curl will prompt for password, if not provided in command.
1Short answer is no... but....
If there are no server side options you can harden the security.
- If this is local intranet then isolate the broadcast domain, and do not use WiFi or any radio.
- As Shameer says, use a .netrc file, keep the values out of the code.
- If you trust that memory is safe, use environmental vars. $PSWD.
- If this is automation, run from root's crontab.
- ...in a container.
- ...from a VM with an encrypted disk.
None of these are any less secure than a browser using HTTP.
