Sorry for being so late in reply. I’m horrible at being social and getting back to people - even my mom when she tells me to call her.
So anyway . . .
Yes, it’s understood that as long as it’s “https” that all data sent is encrypted. I see my username/password in the request string, but that’s before it’s actually encrypted and sent - no big deal . . .except: And here’s a link that contains several of my concerns:
https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
The fact that I see my username AND password in the pre-submission attempt means I’m also relying on the server admins to not store this in logs on the server side (after decryption has been done), that I don’t create a bookmark on my client (any random website can get history without knowledge unless you have taken that proper security measures which are NOT default on most browsers), and that I see my username/password stored in clear text in the error logs on my client.
Yes, I realize that the errors logs having clear text means someone would have to be hacked into my computer to see them, but it’s still disheartening. There are many ways to gain access to the average users computers with tools anyone can download. I won’t go into specifics for obvious reasons, and I’m sure you server admins are aware.
Security by obscurity is often thrown around the industry as a means of being secure, but these “obfuscation” attempts (from experience as an infrastructure engineer myself) tend to be the same tricks everyone uses (I hope you get my drift, again, examples being avoided for obvious reasons).
Just because everyone else provides backwards compatibility (for TLS 1.0 or SSL 2.0 for instance) doesn’t mean it’s secure. That’s a common statement I’ve seen thrown around by admins. Do you fallback to TLS 1.0 if needed? Does the client? What about SSL? I’m not trying to suggest that MusicBrainz follows the common practices I speak of above, only that I’ve read several posts on these very forums (or the dev forums) where the response has been “that’s what everybody else does”. Just makes me question how the storage of my information on the server side is handled. It always scares me to see requests with username/password in the query string itself. There are other ways to go about authentication from client/server - and I don’t like to hear “that’s how it’s been done for decades”, “everyone else does it”, “security by obscurity”, etc.
I’m just being nit picky. I should not have titled my post the way I did, I will admit that :). Just a concerned citizen. Needless to say, I’ve installed Picard 1.3.2 (thanks for the code link, precisely one of the fixes that was in question) and plan on continuing to use MusicBrainz. The prompt feedback definitely makes me feel like you folks are on top of things.
Thanks fellas, truly.
Laggin
EDIT: “there are plans to turn off unencrypted http for the server altogether, so clients (picard or otherwise) will no longer be able (even by mistake) to connect in the clear.” Thank you for that clarification docdem. I was concerned about a few things. Both of my main concerns have been stated or addressed. Sorry for not being clear in my original post. I normally don’t ever post, anywhere, and hate talking/debating/discovery through forums/email/etc. I’m anti social, that’s all.