Is "curl -u username:password http://example.com" secure?

Is curl -u username:password http://example.com secure?

If not, can you give a brief explanation of how someone could obtain your password?

JDiMatteo

Posted 2015-05-26T20:01:50.347

Reputation: 521

6if you are using that in a terminal have you in mind that both credentials are stored in history of bash? – Francisco Tapia – 2015-05-26T20:03:56.590

15Such a command is not secure because another user might use ps -efto see which processes are running. When your curl -u username:password http://example.comappear in the list, your destination, username and password are compromised. – Lambert – 2015-05-26T20:04:23.857

Although the question is on-topic here, you may also be interested in Information Security StackExchange

– IQAndreas – 2015-05-28T06:39:28.350

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.

Dmitry Grigoryev

Posted 2015-05-26T20:01:50.347

Reputation: 7 505

4Even if you're on a platform where curl successfully overwrites its own argv to hide data from ps, there's a period while it's starting up before that overwrite is performed where that content is vulnerable. – Charles Duffy – 2015-05-27T00:25:20.747

What about digest authentication? Doesn't curl use that by default? – rr- – 2015-05-27T09:58:53.860

2@rr Digest authentication is just marginally better, as it does not prevent man-in-the-middle attacks, so you're still better off using HTTPS. – Dmitry Grigoryev – 2015-05-27T10:10:57.773

@rr the decision between digest and basic is made by the server, not the client. – Calimo – 2015-05-27T13:26:17.133

I know it's prone to MITM, but IDK why it's only "marginally" better. The only scenarios I imagine feature an attacker requiring physical access to my or server's computer, or the ISP being untrustworthy. Isn't it enough for most applications? IMO physical access to any computer is fatal on its own, so I must secure it otherwise. – rr- – 2015-05-27T13:33:42.677

I mean, HTTPS certificates cost enough to make me go "meh" when I want to secure connection for my home needs. (StartTLS isn't trusted by most browsers.) If I don't buy a certificate and use a self-signed one, everyone sees a big "connection is untrusted" because they have no way of knowing they connected to me indeed. So I can't secure the connection with HTTPS without securing the connection and proving my authenticity, or without scaring the users away with red banners about self-signed certs. And that's why digest authentication sounds attractive (even if it doesn't encrypt all traffic). – rr- – 2015-05-27T13:40:05.377

"ISP being untrustworthy" is a really common situation in my opinion. Have you ever used WIFI provided by Restaurants/Hotels/Campus/Friends etc? All those people don't make a living from providing you the connection, and have no interest (and often no knowlege) to protect you from such attacks. – Dmitry Grigoryev – 2015-05-27T14:36:37.790

@rr How do you assert StartSSL is not trusted by most browsers? Do you expect many Windows 95 or Firefox 1.5 users?

– Hagen von Eitzen – 2015-05-27T20:10:51.800

I get warnings about untrusted connection on my PC at work (Firefox), on an Android tablet and an Android smartphone (Chrome). True point about ISPs being untrustworthy, I haven't thought of it that way. Gotta get with the times! – rr- – 2015-05-27T20:17:29.277

@rr IMHO you get untrusted only if there's a problem with missing (or wrong) intermediate certs on the server

– Hagen von Eitzen – 2015-05-27T20:19:27.727

It is not secure. Command line parameters are visible to all users.

Tronic

Posted 2015-05-26T20:01:50.347

Reputation: 243

4Merging with @Dmitry Grigoryev answer it could be the most accurate one. – Francisco Tapia – 2015-05-26T20:10:44.527

1Yeah, I completely missed the big part of the problem I must admit. – Dmitry Grigoryev – 2015-05-26T20:18:01.787

command could be part of a script only readable by the user... – Pete – 2015-05-26T23:35:24.827

2@Pete command lines of executing programs (whether started from a script or at a terminal) are typically visible to all users through the ps command and the /proc file system. If the command finishes quickly, the risk is reduced, but it is still there. – RBerteig – 2015-05-26T23:45:11.210

@RBerteig I would agree with you "typically", but what is the typical situation? The truth of his statement is dependent on OS and configuration. The blanket statement is false and I think misses the bigger security issue of sending passwords in the clear... – Pete – 2015-05-27T15:54:37.743

2@Pete Answers are not supposed to be exclusive, they complement each other. So it's OK for the second answer to omit the threat explained in the first, rather, it would be redundant to repeat it. And I wouldn't call the statement false because it's not true in every case possible. – Dmitry Grigoryev – 2015-05-27T21:33:48.270

You may want to clarify "Command line parameters are visible to all users on that computer/server while the command is running (or by looking through stored bash history)." This is a different attack than someone who is a man in the middle or sniffing wireless traffic. – IQAndreas – 2015-05-28T06:42:13.863

This 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

password PASSWORD

Save and Close the file

Use the below to access the URL with Username and Password.

curl --netrc-file /root/my-file http://example.com

Done

Shameer

Posted 2015-05-26T20:01:50.347

Reputation: 11

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

mckenzm

Posted 2015-05-26T20:01:50.347

Reputation: 829

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.

Mohnish

Posted 2015-05-26T20:01:50.347

Reputation: 141

Not a useful answer if HTTPS is not available. cURL is a "client". – mckenzm – 2018-04-25T23:31:21.123