I have made a note of this in my previous post about Magnatune being terribly insecure. Those who follow me on Twitter or Google+ already got the full details of it but I thought I would repeat them here. And add a few notes about that.
I remember Magnatune back in the days in which I hang around #amarok and helped with small changes here and there, and bigger changes for xine itself. It was at the time often used as an example of good DRM-less services. Indeed, it sold DRM-free music way before Apple decided to drop its own music DRM, and its still one of the few services selling lossless music — if we exclude Humble Bundle and the games OSTs.
But then again, this is not a license to have terrible security, which is what Magnatune has right now. After naming Magnatune in my the aforementioned post I realized that I had not given it a new, good password but it’s instead still using one of the old passwords I used to use, which are both insecure by themselves, a bit too short, possibly suitable to dictionary attacks, and I was not even sure if it was using the password I used by default on many services before, which is of course terrible, and was most likely leaked at multiple points in time — at least my old Adobe account was involved in their big leak.
As I said before, I stopped using fixed passwords some time last year, and then I decided to jump on LastPass when Heartbleed required me to change passwords almost everywhere. But it takes a while to change passwords in all your accounts, especially when you forget about some accounts altogether, like the Magnatune one above.
So I went to Magnatune website to change my password, but of course I forgot what the original was, so I went on and decided to follow the procedure for forgotten passwords. The first problem happens here: it does not require me to know which email address I registered with, instead it asks me (alternatively) for an username, which is quite obvious (Flameeyes, what else? There are very few sites where I use different usernames, one of which being Tumblr, and that’s usually because Flameeyes is taken). When I type that in, it actually shows me on the web page the email address I’m registered with.
What? This is a basic privacy issue: if it wasn’t that I actually don’t vary my email addresses that much, an attacker could now find an otherwise private email address. Worse yet, by using the users available in previous dumps, it’s possible to assign them to email addresses, too. Indeed, A quick check provided me with at least one email address of a friend of mine by just using her usual username — I already knew the email address but that shouldn’t be a given.
Anyway, I got an email back from Magnatune just a moment later. The email contains the password in plain text, which indicates they store it that way, which is bad practice. A note about plain text passwords: there is no way to prove beyond any doubt that a service is hashing (or hashing and salting) user passwords, but you can definitely prove otherwise. If you receive your password back in plain text when you say you forgot it, then the service does not store hashed passwords. Conversely, even if the service sends you a password reset link instead, it’s still possible it’s storing the plain text password. This is most definitely unfortunate.
Up to here, things would be bad but not that uncommon, as the linked Plain Text Offenders site above would show you — and I have indeed submitted a screenshot of the email to them. But there is one more thing you can find out from the email they sent. You may remember that some months ago I wrote about email security and around the same time so did the Google Official blog – for those who wonder, no I had no idea that such a post was being written and the similar timing was a complete coincidence – so what’s the status of Magnatune? Well, unfortunately it’s bleak, as they don’t encrypt mail in transit:
Received: from magnatune.com ([64.62.194.219])
by mx.google.com with ESMTP id h11si9367820pdl.64.2014.08.28.15.47.42
for <f********@*****.***>;
Thu, 28 Aug 2014 15:47:42 -0700 (PDT)Code language: CSS (css)If the sending server spoke TLS to the GMail server (yes it’s gmail in the address I censored), it would have shown something like (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); (which appears in the comment messages I receive from my own blog).
Not encrypting the email in transit means that anybody that could have sniffed the traffic coming out of Magnatune’s server would be able to access any of their customers’ accounts: they just need to snoop the email traffic and they can receive all the password. Luckily, the email server from which the email arrived is hosted at a company I trust very much, as I’m their customer too.
So I tried logging in with my username and newly-reminded password, unfortunately my membership expired years ago, which means I get no access at all — so I can’t even change my password or my email address. Too bad. But then it allowed me to figure out some more problems with the security situation of Magnatune.
When you try to login, you get sent on a different website depending on which kind of membership you subscribe(d) to. In my case I got the download membership — when you go there, you get presented with a dialog requesting user and password from your browser. It’s standard HTTP based authentication. It’s not very common because it’s not really user friendly: you can’t serve any content until the user either puts the right username/password or decides they don’t know a valid combination and cancel the dialog, in which case a final 401 error is reported, and whichever content the server sent will be displayed by the browser.
Beside the userfriendliness (or lack thereof), HTTP authentication can be tricky, too. There are two ways to provide authentication over HTTP, one is Basic and the other is Digest — neither is very secure by default. Digest is partially usable, but suffer from lack of authentication of parties, making MitM attacks trivial, while Basic, well, allows a sniffer to figure out username and password as they travel in plaintext over the wire. HTTP authentication is, though, fairly secure if you use it in conjunction with TLS. Indeed for some of my systems I use HTTP authentication on a HTTPS connection, as it allows me to configure the authentication at the web server level without support from the application itself.
What became obvious to me while failing to log in to Magnatune was that the connection was not secure: it was cleartext HTTP that it was trying to get me to log in through. So I checked the headers to figure out which kind of authentication it was doing. At this point I have to use “of course” to say that it is using Basic authentication: cleartext username and password on the wire. This is extremely troublesome.
While not encrypting email reduces the attack surface, making it mostly a matter of people sniffing at the datacenter where Magnatune is hosted – assuming you use an email provider that is safe or trustworthy enough, I consider mine so – using basic authentication extend the surface immensely. Indeed, if you’re logging in Magnatune from a coffee shop or any other public open WiFi, you are literally broadcasting over the network your username and password.
I can’t know if you can change your Magnatune password once you can log in, since I can’t log in. But I know that the alternative to the download membership is the streaming membership, which makes it very likely that a Magnatune user would be logging in while at a Starbucks, so that they can work on some blog post or on source code of their mobile app while listening to music. I would hope they used a different password for Magnatune than for their email address — since as I noted above, you can get to their email address just by knowing their username.
I don’t worry too much. My Magnatune password turned out to be different enough from most of my other passwords that even if I don’t change it and gets leaked it won’t compromise any other service. Even more so now that I’m actively gathering all my account and changing their passwords.