MusicBrainz client not secure - Unencrypted username/password passed during logon to https session

Wow, I was becoming a huge fan of MusicBrainz until I noticed an error in the error log:

https://myusername:mypassword@musicbrainz.org/

I haven’t done the research as to why my username/password was sent via the client to server in CLEAR TEXT, but it was immediately obvious there is a big security issue with the client. I’m sure the devs are already aware of this, and it’s probably noted somewhere on these boards - but that kind of insecure behavior makes me wonder what other kind of security issues the client has.

Great software, great service - wish it were secure. Very sad indeed. Easiest middle man attack ever.

If your log really says http s, then your connection is actually encrypted. So an attacker can not easily sniff your password on the wire.

There are possible attacks, which I will not list for sake of brevity, but this is not one of them.

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.

4 Likes

Which version of Picard do you use ?

https://github.com/metabrainz/picard/commit/4a471528e2405f300eba1c212f26fa6c312f71b5 should have remove this issue.

By “this issue”, you mean the issue that the password was put into the log, right? Because this is a different issue than what @Laggin was speaking about, who appears to think that the password is transmitted in the clear over the wire.

Not really sure what @Laggin is speaking about.

I read

and thought about the password in logs.

About password in communication, it seems obvious the posted URL is using HTTPS.

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 . . . :slight_smile:

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.

That’s not a query string; it’s HTTP Basic authentication. Not very frequently used, but if you’ve seen your browser pop up a dialog asking for a username and password—that’s it. http://user:password@domain/path is just filling in the username and password in the dialog. It shouldn’t be sent as part of a Referer, and that’s not really relevant if it’s Picard.

It isn’t sent to the server like that at all, instead it’s put in a separate header. The default config with most servers is to log the username.

It’s possible your browser would create a bookmark with the password in it—but again, not relevant if it’s Picard talking to MusicBrainz.

If it’s being logged to disk (on your machine), that’s bad. It shouldn’t be. Also, it shouldn’t be displayed, to prevent someone from looking over your shoulder and seeing it.

2 Likes