In this particular incident, sponsors' passwords are visible in the URL they use to access their stats. Moreover, those URLs have leaked onto Google, complete with password. And the powers that be at TMP seem remarkably unbothered about this.
Let's take a step back to a topic we discussed last year when some Kickstarter passwords leaked, and revisit the question of how passwords work, and all the security risks involved, step by step. Be warned, though, by the time I've finished I should have turned you into a paranoid wreck.
You type in your password.
There's a whole PILE of risks right here.. is your machine (is it your machine?) infected with a virus or trojan that's logging your keystrokes? Given a badly-designed web forum (say), I can install a keylogger on your browser by simply having you read a carefully crafted forum post.
Are you being watched (physically 'shoulder surfed')...?
Your password is sent to the server.
And the first question here is 'is it?'
Do you trust the wifi access point you just connected to? Really? Give me a morning, and I can knock together a very nice, convincing-looking access point which returns the WRONG answer to (say) 'where is Paypal' and presents you with a fake Paypal login page and grabs your password, then says 'sorry, login denied'.
And even if it is the right server, it's not immune to being 'sniffed' - if the server isn't talking HTTPS (the secure, encrypted way for you to talk to a web server - check for the padlock icon) then the channel between you and the server is NOT encrypted, and you're fair game to anyone who happens to have the ability to snoop... Give me that same morning, and I can build an access point that routes all the unencrypted traffic it receives through a proxy that looks for user credentials and takes a copy without you ever knowing (really, do you trust ALL the access points in the shopping mall, or airport?). Or I could probably wave a few Bitcoins somewhere on the Dark Web and get a device mailed to me that already does that.
(Oh, and just because the site responds to HTTPS doesn't mean it's safe: if you click on the little padlock icon, it'll tell you which organisation the security certificate is registered to - if it doesn't match the organisation you believe you're connecting to and it hasn't expired, something's amiss. Either that or someone's being appallingly sloppy with their security certificates.)
The server checks if you have the right password.
Now, as we discussed before, the way this is supposed to work is that your password is stored with a one-way encryption, i.e. one where creating the encrypted password is easy, but recovering the original text is prohibitively difficult. All the server has to do is encrypt the password you supply and see if it matches the stored encrypted one, it never has to, and never SHOULD, store the unencrypted one. (Unless, of course, it's being malicious.)
Of course, if you're lazy, ignorant, or bad, you don't bother encrypting the password, and store it in plain text. (One easy way to tell? tell the site you forgot your password: does it ask you to enter a new one, or send you the old one? If it's the latter, this is not good. Equally, does it do anything else (TMP, I'm looking at you) that indicates it knows your password?)
Why is this a risk?
If it's sniffable, or Googleable? You're at risk, obviously. If you're sloppy, and reuse passwords on other sites, you're doubly at risk. The defence 'but it's hard to find and/or not very important' isn't a good one either. This is 'security through obscurity', which is no defence at all once you've breached the obscurity!
To my mind, this indicates a lack of understanding of some key concepts in security, that or a dangerous level of arrogance. If I found a risk like this in my day job, I'd be looking even harder for other issues. If I as a security professional would, you can bet your bottom dollar there's some hacker out there having a good poke around TMP right now, in the hope of finding a backdoor into a database full of unencrypted passwords.
Passwords are gold. Passwords and the email addresses they belong to are better than gold, because people are generally lazy and sloppy about password reuse.
Do you even know you're accessing the site?
You're probably all looking a little blank here, but: suppose that it's possible for you to perform an action on your target site by sending it an appropriately crafted URL without any other human interaction - let's say for the sake of argument, you can award a customer a gift voucher (this is appallingly bad development practice, BTW - don't do it!). I send you an email, containing a handcrafted URL that I know awards me a gift voucher, as an image link.
The web browser in your mail client (c'mon, how do you think your mail client displays HTML mail) tries to fetch the image. Obviously, the reply it gets back won't be an image, so you'll see the broken image icon. But, you will still have accessed the URL, and hey presto, I just got a gift voucher and it looks like you legitimately gave me it.
Change your password. Use a password manager. Don't use the same or related passwords on different sites. Don't blindly trust unknown web access points. Don't trust sites that are flippant or dismissive about security issues.Also, don't insert USB sticks you pick up in the car park or receive via unsolicited mail to find out who owns them or where they came from. But that's another story.
Disclaimer: just in case it's not obvious? I am an IT security professional: part of my job involves looking for places where my colleagues have, accidentally or through omission or laziness, released security risks into our code. In my job, the bad guys only have to win once: I have to win every time.
I do not use or condone any of the above techniques, except where used as penetration test tools by the likes of me to validate the security of software with the author/owner's explicit consent. And the above techniques are all public knowledge - for crying out loud, most of them have their own Wikipedia pages! So please don't run screaming to accuse me of being a hacker, or enabling hackers.