SeaMonkey and user credentials on the URL

Phishfry

Phishfry

Seamonkey stopped allowing user login credentials on the URL bar without an about:config setting and I still get an annoying popup.
I use this feature and think it is handy.
A sanitized example from my network cams:
http://admin:password@192.168.1.28/cgi-bin/video.cgi?msubmenu=mjpg
.
screenshot2.png
I realize there could be security implications but this is my private network.
 
Definitely security implications and I wouldn't ever do this in the "wild", but since on your own LAN, no issues, unless someone is on your LAN that you don't know about ;)
 
Yes, but the problem with using uname and password in a GET request is that that data is stored in server logs, browser cache and possibly proxy cache as clear text. If those items are under your control fine, but if doing this over the Internet, even with HTTPS, you don't know where the username and password are going to be stored in the clear and for how long.
 
Sevendogsbsd said:
... but if doing this over the Internet, even with HTTPS, you don't know where the username and password are going to be stored in the clear and for how long.
Click to expand...
They will only be stored in cleartext on the sending machine (where your browser runs), and on the receiving machine (where the server runs); the middle transports opaque SSL packets.

If you don't trust the machine where your browser runs, you have a much bigger problem than logs. And if you don't trust the server, you should probably not type your username and password into it.

(Leaving the fundamentally unsolvable problem of a server that you need to use, like your bank or insurance company, but that later turns out to be not trustworthy because they were were sloppy and careless. That's a tough one.)
 
Keep in mind there may be other devices en route such as proxies or load balancers that may decrypt and re-encrypt traffic (for deep packet inspection) . In a web application, most times the username and password are sent using POST and are only encrypted within the HTTPS tunnel. Personally, I would never send creds or any other sensitive data in a URL and it is not an industry best practice.

OWASP, Example 2, OWASP Auth Cheat Sheet

Too many more to list. My .02
 
You seem to assume, that the optional userinfo@ component of the URI which you enter in the address bar would go over the line as is, as part of the host component of the URI. It won’t. The browser takes this info and moves it into a regular HTTP Basic authentication request header field, which would be encrypted by TLS like any other header/content of GET, POST, etc. requests. Your OWASP links refer to Query strings, that is the stuff after the ? at the end of the URI, and this is a completely different animal. So in respect to the risks involved, I agree with ralphbsz.
 
Didn't realize that obsigna, thanks for pointing that out. I have seen sensitive data passed in querystring params so thought this was the same. Thanks for the clarification.

Keep in mind though that basic auth is only base64 encoded so anywhere it is stored is easily decoded. If that's not a problem, then it's fine.
 
Anyone who puts username or password into the today URI is a fool. I'm sure fools still exist. They are probably one of the larger threats to privacy and security. But they should be slowly eliminated, by educating them in how to do it right.

And if SSL can be decrypted by regular deep packet inspection, which all brands of routers do, then all our ideas about security are sunk, and we might as well give up. (I'm deliberately excluding "national technical means", a joke buzzword for things that officially don't exist and that nobody can talk about.)
 
You must log in or register to reply here.
Back
Top