Change your Last.fm password

http://thenextweb.com/insider/2012/06/07/change-your-last-fm-password-now-there-may-have-been-another-security-breach/

by luiperd • 14 years ago

150 146 14 years ago

thenextweb.com

tptacek3• 14 years ago

17.3 MILLION MD5 hashes (unsalted, not that it matters), of which over 16 million have already been cracked.

jgrahamc4• 14 years ago

Says who? Not that I don't believe you.

EDIT: The developer who apparently implemented the password hashing replied to me on Twitter: https://twitter.com/russss/status/210783976879693824

tptacek3• 14 years ago

Says these people:

http://contest.korelogic.com/

Check out the twerps at @CrackMeIfYouCan.

raverbashing2• 14 years ago

What?!

This means next leak will be one million CRC32 password hashes?

Or maybe LM hashes. Or crypt on old /etc/password files

tptacek3• 14 years ago

This was funny, and I laughed, but the irony is that old Unix crypt(3) is probably better than MD5 or SHA1.

jgrahamc4• 14 years ago

Well, the Gawker hack was DES IIRC.

lanstein• 14 years ago

ROT13?

SourPatch• 14 years ago

Don't forget last year around this time when Sony's PSN was cracked into and it turned out they were storing the cleartext passwords.

hpaavola• 14 years ago

Passwords need to die. There will always be bad implementations on storing passwords and those will hurt many users. We need something better.

markkum2• 14 years ago

If you want something better for your site; check out MePIN https://www.mepin.com/

jackalope2• 14 years ago

How do they prevent unauthorized locks, unlocks or transfers? There's virtually no documentation on the site.

quesera• 14 years ago

Well, the problem here is that big corps are doing obviously-wrong things with user data. It's not like there's any uncertainty in the industry about how to do things correctly, it's just that these corps and many others are deciding not to.

What makes you think they would make better decisions if the technology was called something other than "passwords"?

There is no technology that cannot be ruined by ignorant implementation.

Passwords suck for other reasons. This is a poor example.

jackalope2• 14 years ago

Let me tell you a secret. Now that I've told you, it's no longer a secret. That's the problem with passwords.

ihatecats• 14 years ago

> Well, the problem here is that big corps are doing obviously-wrong things with user data

Totally true. One service of a rather large European bank stores passwords in plain text. It's just waiting to be exploited.

pnathan2• 14 years ago

I would like to see pub/private key implementations for this sort of thing.

pavel_lishin• 14 years ago

I find it so odd that this functionality wasn't baked into web browsers from the beginning.

flyt• 14 years ago

Easy: everybody authenticate with Facebook Connect, then we just have a single location and storage mechanism to secure.

dchest• 14 years ago

Ha-ha. And nothing goes wrong.

joshuahedlund• 14 years ago

s/secure/crack.

betterth• 14 years ago

As silly as it is, it's what I'm doing for a lot of my non-essential sites. Being able to see who I've signed up with is also nice, as I'm sure I'm signed up to a whole host of sites that I have zero memory of.

That, and Facebook supports two factor authentication and (hopefully) isn't leaving their pw db as unsalted md5...

waffle_ss• 14 years ago

I like using OpenID. I just use my domain name as a delegate and point it at my current OpenID provider of choice for authentication (which is currently my Google profile; used to be myOpenID 'til they went down for 1/2 a day). As long as I retain my domain name, I can control authentication, even if my current provider were to be compromised (just point my domain name/delegate at a different provider).

The problem, of course, is a lot of sites still don't support OpenID.

0x0• 14 years ago

Do LinkedIn, eHarmony and LastFM have any parts of their software stack in common? Same 0day?

ig1• 14 years ago

They're all Hadoop users.

timdorr• 14 years ago

I doubt their Hadoop clusters have password data stored in them.

benpbenp• 14 years ago

Or perhaps some eHarmony and LastFM employees used sensitive passwords for their LinkedIn accounts.

ch0wn• 14 years ago

More probably the same mindset regarding security. I wouldn't expect a company that stores unsalted passwords to invest much in security elsewhere.

toyg3• 14 years ago

Apparently this breach is a year old, so nothing to do with it. Maybe they just decided to go public today hoping that focus would remain on LNKD or (even better) people would just think "ah well, it can happen to everybody".

ronnoch• 14 years ago

I was worried for a minute, but I can't actually think of anything a hacker could do with my last.fm account that I care about.

jasonkester2• 14 years ago

Last.fm sounds like the canonical example of a site that where it makes absolutely no difference if your password gets exposed.

Worst case, some malicious individual on the internet will learn that I still like the Beastie Boys, even though it's not 1994 anymore. And possibly they'll listen to music in my name.

This is why one has a throwaway password. For throwaway accounts at throwaway sites like this. Getting your throwaway password thrown away should by definition not be something you worry about.

pimeys• 14 years ago

They'll get your username, they might crack your password.

Do you use the same password/username combination somewhere else? If not, good for you. You're kind of a rare person.

chc• 14 years ago

Even if you don't use the same username, if they have your email, those are fungible with usernames on many sites. (And of course game over if you use the same or similar password for Last.fm and email.)

praxulus• 14 years ago

I reuse passwords for websites like that, but the other places I use it are similarly throwaway.

jasonkester2• 14 years ago

Yes. That's the point.

Not only will they be able to listen to music that I like, they might be able to download MySQL as though they were me or comment on Engadget articles as me.

None of which are particularly concerning. Because those are throwaway accounts for me.

pclark3• 14 years ago

I have over 150k songs scrobbled to Last.FM and have been a member since 2005. I actually can think of very few other services that I would care as much as if my Last.FM was compromised/deleted.

earbitscom• 14 years ago

I can see it now...

Show HN: pclark listens to Miley Cyrus, A LOT.

georgespencer2• 14 years ago

Same. 127k songs since '05, and I still cruise through the site regularly and look at what i was listening to on this day in 20xx.

I briefly paid for the site's radio functionality before it was crippled. It feels to me like they've died a similar death to Flickr (acquired, core team left, innovation stopped). Such a shame.

mnicole2• 14 years ago

Ditto. 196k since '05 here. The ability to see how my musical taste synced with the ebb and flow of my life is something I really cherish.

bombtrack• 14 years ago

Same feelings. I treasure my last.fm stats so much. It has documented 7 years of my life in a way that no other site or social network could express.

mtkd• 14 years ago

It matters because there was a failure and it could be in a technology or service you also use.

It matters because many users re-use credentials.

Scenario: You send a confidential email to a colleague, colleague has her lastfm compromised. Attacker scripts up logins against all common sites - including her Gmail account where you sent your confidential email. Script not only logs in and changes password, it also forwards to her friends and family all the emails containing some target phrases - including your confidential one.

niels_olson2• 14 years ago

anyone care to bet everyone with a linkedin account who works at a tech company just got targetted attacks? Hi, my name is Joe Hacker, and I work at <domain name>! Since you got my linkedin account, why not try that password at admin.<domain name>?

luiperd• 14 years ago

But how many people have throwaway passwords on sites like these? It might not mean much to the tech-savvy community, but I'm sure a lot of people use the same password for a lot of services.

They might not be able to do much with your account on Last.fm, but they have your email, for which you may or may not use the same password.

taylorbuley• 14 years ago

Most people reuse passwords across services. If that's the case, a breach in any one service becomes a foothold into a panoply of other accounts.

cesare• 14 years ago

Last.fm also has an affiliate program for labels (http://www.last.fm/uploadmusic).

By gaining access to these accounts you can do a lot of damage (eg. steal money from people accounts or destroy a label presence on last.fm).

georgespencer2• 14 years ago

Does anyone have a dump of the hashes?

StavrosK2• 14 years ago

I saw this in another thread today, and I am never NOT using it again:

http://supergenpass.com/

soulclap4• 14 years ago

To be 'fair': when Last.fm first launched, md5 was probably 'state of the art'. I mean take a step back, they have been around for like forever.

The question is: How would you go on about moving your user database from md5 to a more advanced algorithm? Validate a user's password on log-in and then encrypt it with the new, more secure algorithm?

cschmidt2• 14 years ago

Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else:

_______

Password upgrading

When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented.

https://docs.djangoproject.com/en/dev/topics/auth/#password-...

_________

So it would be trivial for the big sites to have switched transparently to a safer hash, even if MD5 was Ok when they started. You could also add salts in the same way, if you were storing unsalted hashes.

raverbashing2• 14 years ago

Kudos to Django because this is very important

Like in bcrypt discussion saying you can tune the amount of work. Sure, but what to do with the existing hashes!

Of course, the user needs to retype their keys, but it's better than keeping old credentials.

(or maybe you save the original credentials with strong PK crypto, together with the hash, then periodically decrypt offline and rehash)

pek2• 14 years ago

Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until the users log in.

soulclap4• 14 years ago

Great feature. So you alter the password field (extending the length) if needed and when a user signs in it gets auto-updated and Django always tests both/all specified algorithms? Or do you have to add a new database field when moving on? (Sorry for my tl;dr behaviour but while I've got an expert on the line anyway...)

notlostyet• 14 years ago

You can also just hash the existing hashes. bcrypt(salt + old_md5). New passwords can use a new MD5-less scheme.

mikeash• 14 years ago

I don't believe straight unsalted MD5 was ever state of the art for password hashing. Yes, it was a state of the art cryptographic hash at one point, but those are not the same thing.

jedbrown4• 14 years ago

Unsalted was not "state of the art" in the 1970s. The database would be far more secure if it had used a weaker hash with salt.

To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.

soulclap4• 14 years ago

You are right, I just meant to say that the 'awareness' has increased a lot since Last.fm first stepped on the scene. Unless you were already security-savvy and had a hacker (as in the original sense of the word) background, I guess no one really cared back then.

On a sidenote, I just changed passwords for what was probably my second last.fm account and I haven't logged in or 'scrobbled' since 2007. Different times for sure.

anigbrowl2• 14 years ago

Jeepers, I just changed my linked in password. I had the source for PGP back in 1993, I don't recycle passwords for anything remotely important, I use gnarly long passphrases, two factor authentication and what-all else, and I AM SICK OF IT. I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. I'm tired of the maintenance security imposes on me, the lack of a meaningful industry certification, and on developers' insistence that I use passwords of between X and Y length and containing particular combinations of characters, numbers, etc.

Every time I read about one of these avoidable breaches, I feel tempted to gin up a class action lawsuit and force a company to either write a painfully large check to acknowledge the time and trouble it has imposed on its customers - say, about $5 each - or sell itself to its users in lieu of money. I'm not actually going to go to that effort, but sooner or later some enterprising law firm will, and I'm sure everyone here is going to be all hand-wringy about it.

We need to automate security and make it customer-centric. It is plainly too complicated to be left to individual web service providers, just as brick-and-mortar stores do not manufacture their own door locks or burglar alarms. Vendors, if you feel you can't safely outsource this job to a third party, then you need to hire full-time security monitors and start facing up to security as a line-item cost rather than a check-box you can forget about after you've put it in place.

Sorry to be ranty, but when established firms are losing millions upon millions of passwords literally on a daily basis, something is drastically wrong with the state of the art. This is a problem that can't be prettied away with CSS or smoothed over with a few tweets and blog posts.

sliverstorm• 14 years ago

I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops.

Fundamental flaw with that- you can't change your fingerprint if/when it is compromised.

TeMPOraL• 14 years ago

On the other hand, it's much harder to crack a hashed thumprint image.

[edit]

evan_ is right, you don't hash scan images. The question is, how much usable bits of entropy you can extract from a thumbprint scan? Anyway, I retract my main point.

astine2• 14 years ago

Just switch fingers.

pbhjpbhj• 14 years ago

Some people dont have fingerprints. How will you handle them?

obituary_latte• 14 years ago

Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.

It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here to provide a subject for you to point your finger at should there be a breach".

WTF, industry.

wdewind• 14 years ago

I also have Chase and have heard the explanation for not allowing symbols in passwords to be that they are harder to grep out of logs if someone is keylogging you. Seems like BS to me, but either way is is extraordinarily frustrating to not be able to use a strong password for your bank.

Something even more ridiculous Chase does is assign a default pin of '3210' to checking accounts.

cydonian_monk• 14 years ago

At last Chase allows us to have rather long passphrases (mine is well over 16 characters). Discover has the same alphanumeric-only rule, but limits you to 10 characters. 10. Then we have the silly little sites that don't retain any important information aside from a contact email that force you to have high entropy and two-byte non-latin characters in your password. (OK, so that's an exageration, but not much of one.)

jcromartie2• 14 years ago

Many banks are encumbered by old mainframe systems that still do a lot of their computing. I don't know how much of that bubbles up through to the web interfaces we deal with, but I know many tellers and agents are still on green screens, or on interfaces that are just pretty wrappers to mainframe terminals.

cf0ed2aa-bdf5• 14 years ago

My (German) bank only allows passwords up to 5 characters.

When I ranted about it on twitter some IT guy from a local branch commented about that is totally enough since they do an hour lockout after 3 wrong tries.

I'm thinking about switching banks now...

dhughes• 14 years ago

TD Bank is the same, maximum is eight characters and no special characters for the password.

I spoke to them and got a flustered "Well would you like me to mention that to our IT department?"

It's only been like that for 15 years maybe they should look into it!

nitrogen3• 14 years ago

Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.

Special characters don't make as much of a difference as password length: http://xkcd.com/936/ (a comic that must appear on any password-related thread). According to the XKCD analysis, an 8 character password based mostly on letters with some numbers and symbols has ~28 bits of entropy, while a random four word password has 44 bits. [Edit to add: http://news.ycombinator.com/item?id=4083381 claims over 3 billion MD5 hashes a second for $1000, meaning your 28-bit password could be cracked effectively instantaneously by a high school kid buying phishing gear with stolen credit cards or a summer job].

If you're an international web site, it might make sense to disallow symbols, as your customers may not be able to enter their chosen symbols when traveling internationally.

zerostar07• 14 years ago

What about browserid, openid etc

anigbrowl2• 14 years ago

I'm not really knowledgeable enough to rate different solutions, which is why I resorted to ranting rather than articulating a good alternative or working on one myself. Security is something that I have to do rather than something I am personally excited by, and I don't actually want to be encrypting everything for the same reason that I don't want to live in a bank vault or build a ten foot wall around my property.

I guess what I'm saying is that I will pay for a frictionless system whose operator is prepared to place a cost on failure, same way that I am willing to pay for a decent padlock or mortise lock for my physical property. It doesn't have to utterly impenetrable, but I would like the security provider to have skin in the game.

I thought openID was an excellent idea; I'm not sure why it didn't take off, maybe Google took too much of a monopolistic approach or something.

tomg• 14 years ago

You can get rid of a huge amount of password-related frustration by using a good password manager (not the rinky-dink ones that browsers come built in with).

I've been very satisfied with 1Password and I can't imagine going back to not using it.

phase_92• 14 years ago

I've just spent the last couple of hours creating unique longins for every site I can remember having a login for and storing them in Keepass (opensource password safe). The Keepass database is stored on my dropbox account so it's automatically synced to all machines / devices I use.

I get the impression this is going to be a bit of a PITA, but with the rate these sites are being breached it's probably a sensible move.

tzs2• 14 years ago

> I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops.

MythBusters looked at fingerprint scanners in episode 59, "Crimes and Myth-Demeanors 2". They were able to easily bypass both the cheap consumer models and an expensive professional one with advanced features that supposedly check for body heat and a pulse to make sure you aren't using a fake finger.

Another problem with biometrics: it allows unapproved sharing of identity information. If I use a fingerprint or iris scan or some such to identify myself to entity X and to entity Y, then even if I'm using different names with X and Y, they could compare biometric data and correlate my identities.

astrodust• 14 years ago

All they needed was a photocopy of your thumb-print that was licked, stuck to your thumb, and applied to the scanner. If it was 'warm' enough and had some kind of pulse, you were in.

The "Jell-O finger", made much the same way, using a standard electronic board etched to make an inverse thumb-print also worked freakishly well.

jameswyse• 14 years ago

@CrackMeIfYouCan posted this on twitter:

A bit of stats on last.fm leak:

1) It happened a WHILE ago. 2010/2011

2) 17.3 million raw-md5

3) 16.4 million cracked. 95% cracked.

drostie• 14 years ago

Nice to hear. I had thought that perhaps one of their higher-ups had used the same pass on LinkedIn as on Last.fm and had noticed suspicious activity. Now I know that they just googled to see, "oh, did anyone hack us? they did?! OVER A YEAR AGO?!"

kalininalex• 14 years ago

Any info on how and why so many were cracked? Passwords too simple?

darklajid• 14 years ago

MD5, unsalted. On commodity hardware you can compute those blazingly fast. A brute force attack, ignoring word lists, is totally possible.

That's ignoring all the resources that offer access to precomputed hashes (I don't want to call a list of MD5 hashes a rainbow table).

Easy or not, passwords saved with this scheme are unprotected.

phase_92• 14 years ago

Unsalted MD5s. http://www.codinghorror.com/blog/2012/04/speed-hashing.html

toyg3• 14 years ago

WTF, A YEAR AGO ?? They didn't notify users (i.e. me). Aren't they in breach of California law? Where are they based?

evan_2• 14 years ago

maybe they're just learning about it

majke• 14 years ago

And WizzAir keeps passwords in plain text. What can be done to shame them?

reidrac• 14 years ago

Last.fm Password Security Update

http://www.last.fm/passwordsecurity

jgrahamc4• 14 years ago

Is there a cryptanalytic reason why a company that has a database full of MD5/SHA1 hashes can't perform a one time upgrade by computing bcrypt(salt, the_old_hash) for every hash they have in the database and then when someone logs in do bcrypt(salt, md5/sha1(password)) to check the password?

jedbrown4• 14 years ago

It looks like that is what LinkedIn claims to have done.

http://blog.linkedin.com/2012/06/06/linkedin-member-password...

timjahn• 14 years ago

"...which includes hashing and salting of our current password databases."

Does this mean before this leak, they didn't hash/salt passwords?

joelthelion• 14 years ago

per-user salt.

hinathan• 14 years ago

That's a perfectly reasonable approach — we did that at PBworks a long time ago. Totally transparent to users if done right. You can also declare password bankruptcy and zero out everything. That forces password resets for your entire user base. The latter approach doesn't go over so well with users or support staff but it is much simpler.

dunk010• 14 years ago

The auth.getMobileSession method in the 2.0 API, and the scrobble 1.0 API were both sticking points.

chrismsnz• 14 years ago

That's what I did when I migrated our application to bcrypt some time ago.

I had some questions about whether using an md5sum as the bcrypt input, with much less keyspace (only hex characters) had any impact on security but nobody could/would answer.

I'm guessing that knowing that the plaintext for the bcrypt hash is always going to be 16 characters of 0-9,a-f might have some impact on crypto analysis but considering the passwords most people use I'm guessing it's only going to be a net win in terms of entropy.

bigiain4• 14 years ago

Yeah sure, bcrypt(salt, md5/sha1(password)) is in general less "secure" than bcrypt(salt,password)#, it's still more secure than md5/sha1(password).

# Note though, that you need at least 20 printable ascii chars to get the 128 bits of entropy possible in an MD5 hash, so for _most_ passwords, you could optimize your cracker by only bruteforcing bcrypt(salt, md5/sha1(password)) using shorter strings as password guesses rather then needing to bruteforce the whole 128 bit MD5 space. With bcrypt and salt though, that turns into an "only practical for state-level attacker" I think.

aidos• 14 years ago

I've been wondering the same thing myself recently. I know of a number of legacy systems that could do with this but I'm unsure of how cryptographically safe it is (bcrypting md5. Would love if someone with knowledge in the area could confirm that it's ok.

tthomas48• 14 years ago

Wouldn't I want to keep my last.fm password static lest they leak my new password?

guelo• 14 years ago

Here's the method I use to manage website passwords: For logins that I don't really care about that much, say last.fm, I use my standard medium-strength 6 character password with a number and a capital letter, something like jfi3Jo. I can remember it because I use it often. For logins that I do care about like my email or bank I salt my base password by inserting three characters from the site's domain name into the front, middle and end of the base password. For example, my login to Hacker News would be yjfic3Joo, where yco from ycombinator.com is added in the front middle and end of the base password.

I know it's not the most secure method in the world but I think it is a good compromise between remembering the passwords and providing a unique-per-site decent strength 9 character password. If someone figured out my scheme they could get into all my accounts but in order to figure out my scheme they would have to brute force crack two of my 9 character passwords from hashes from two different sites and then match up the two accounts and compare the differences, that is the risk I currently take.

nadinengland• 14 years ago

I wrote a large paragraph on now I do my passwords then realised how silly it is to tell the world :D

adambyrtek• 14 years ago

News of this kind make me even more glad that I use random generated passwords for every site, with LastPass to manage all of that. (Waiting for a snarky comment about LastPass being supposedly hacked some time ago.)

jyap• 14 years ago

I just changed my password and deleted my Last.fm account. Just because I changed my password doesn't mean a new MD5 hash of my new password won't leak tomorrow. If you can't trust the service, don't use the service.

To delete your Last.fm account, go to the "Data" tab in settings. Click on "Delete entire account for user".

smsm42• 14 years ago

Looks like passwords need to be replaced with something else, obviously most companies, excluding none, are completely unable to handle them properly. Time for a big disruption.

ricardobeat3• 14 years ago

I doubt my new password will be any safer, so I can't really use one which follows my current pseudo-random patterns.

I'm now convinced that password managers, with random generated passwords, are the way to go. At least they have a strong incentive to focus on protecting user data. Still scared of not knowing my own passwords, and giving them to a third party, though.

Arelius• 14 years ago

Agreed, I would never trust my passwords to a private third-party with closed code-base. And KeePass still seems a little meh, especially regarding device support. So for now I'm using an encrypted file synced with DropBox.

tosh2• 14 years ago

Holy cow.

Apparently reporting the vulnerability to them 5(!) years ago was not enough :/

http://discuss.joyent.com/viewtopic.php?pid=139497

* Communicate over SSL/TLS (avoids session hijacking scenarios and is a reasonable choice in general)

* Hash AND Salt user passwords (we use PBKDF2)

Take one day and fix this in your own products & you just saved yourself a major PR disaster in the future :)

gioele• 14 years ago

It is OK to suggest users to change their passwords, but shouldn't they stop sending their session cookies over plain HTTP? Session hijacking is now widespread and an easy way to get into non-important accounts and then escalate to more interesting accounts.

[1] https://www.owasp.org/index.php/Session_hijacking_attack

PS: I'm leaving this comment without any reference to the site name, so I can copy and paste it verbatim in the future; it looks like this kind of breaches will not stop soon.

nitrogen3• 14 years ago

PS: I'm leaving this comment without any reference to the site name, so I can copy and paste it verbatim in the future; it looks like this kind of breaches will not stop soon.

Be aware that there is the possibility[0] that HN's (or other sites') anti-spam features may detect a copy-pasted post as duplicate or artificial content, and kill it and/or your account. It's probably better to add a link to the original post, with some article-specific text.

[0] Based on speculation and inference, not actual knowledge.

sunwatcher• 14 years ago

There's a great deal of room for improvement in password protection, which would make stealing a password very difficult. Some discussion on developments in that front here: http://news.ycombinator.com/item?id=4047968

Change your Last.fm password

Related Stories