
Change your Last.fm password - luiperd
http://thenextweb.com/insider/2012/06/07/change-your-last-fm-password-now-there-may-have-been-another-security-breach/
======
anigbrowl
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.

~~~
obituary_latte
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.

~~~
jcromartie
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.

~~~
tzs
I've heard that excuse from banks and such before, and, frankly, I suspect
they are lying.

Oh, I fully believe that whatever ancient mainframe they are using might limit
passwords to some small number of mono case characters with no funny
characters allowed.

However, that would only apply to passwords for mainframe accounts. The bank
is NOT going to be creating a login account on the mainframe for each bank
customer. Our bank accounts are just entries in an application database on the
mainframe.

If there is some kind of per customer password that the mainframe stores with
the bank account data and that the online system has to provide when sending
transactions to the mainframe, and it has such a limit, and the bank cannot
update the application and database for some reason, that still should not be
visible to the customer doing online banking.

The part the customer sees online should have its own password database, which
allows good passwords, and in there it should have (encrypted!) whatever the
ancient limited mainframe password is for that customer's account.

Unless the web interface itself runs on an ancient mainframe, I strongly
suspect that there is no acceptable excuse for only allowing short passwords
from a limited character set.

Banks are simply not very good at security, or they don't care. Hell, they
insist on mailing me things that include my full credit card number, ensuring
that someone who wanted to inconvenience me just has to drive by my mailbox at
the right time and steal my statement. How freaking hard would it be for them
to X out all but the last 4 digits. Yes, that would mean someone whose
statement covers multiple cards might have a collision--so don't issue two
cards with the same last 4 to two people who receive a joint statement.

~~~
ricardobeat
The reason they don't allow special characters is to prevent situations where
the customer has forgotten his password and needs to go through an
excruciating verification process to access his own account.

------
jgrahamc
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?

~~~
chrismsnz
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.

~~~
bigiain
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.

~~~
__alexs
Only for users with >128/160-bits of entropy in their password, which probably
means your password is well over 20 chars long.

------
jasonkester
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.

~~~
pclark
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.

~~~
georgespencer
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.

~~~
pclark
Agreed. Last.FM is such a trove of data. It is fascinating to see what I was
listening to and when, and especially looking at macro events and seeing how
that influenced the worlds listening habits.

It took Last.FM until 2012 to implement the ability to find your friends from
Facebook. Seriously. It really is such a shame; they're a service that needs
to be spun out.

~~~
phildeschaine
Their event listings used to be my go-to place to find out about concerts. The
problem is they have a bug they've never fixed (after at least 2 years) where
you can't see events happening on the current night. I think it's related to
timezone, and the fact they are based in the UK.

Now I've got songkick, which kicks ass at keeping me informed about shows. But
the whole reason songkick is so effective for me is that I imported my
listening history from last.fm when I first signed up.

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

~~~
raverbashing
What?!

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

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

~~~
lanstein
ROT13?

~~~
DrCatbox
Ive seen a legacy application still in use which puts the password in a (non-
secure) cookie as ROT13 and cleartext in the db.

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

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

~~~
joshuahedlund
s/secure/crack.

~~~
StavrosK
Also one password to change, though.

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

~~~
ig1
They're all Hadoop users.

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

~~~
jen_h
It would be very foolish, but I do wonder if they used Hadoop to compare their
hashes with publicly exposed hashes after breaches of other sites (for
example, Gawker or Zappos) in order to force reset affected users.

------
jameswyse
@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.

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

~~~
darklajid
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.

------
tosh
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 :)

------
georgespencer
Does anyone have a dump of the hashes?

------
guelo
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
I wrote a large paragraph on now I do my passwords then realised how silly it
is to tell the world :D

------
gioele
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.

~~~
nitrogen
_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.

------
smsm42
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.

------
ricardobeat
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
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.

------
ronnoch
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.

------
soulclap
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?

~~~
cschmidt
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-...](https://docs.djangoproject.com/en/dev/topics/auth/#password-
upgrading)

_________

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.

~~~
raverbashing
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)

~~~
powersurge360
In regards to "what to do with the existing hashes" bcrypt can detect the
original work factor and hash to that. Not sure how you would upgrade that for
users, however.

------
jyap
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".

------
sunwatcher
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>

------
adambyrtek
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.)

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

------
reidrac
Last.fm Password Security Update

<http://www.last.fm/passwordsecurity>

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

------
StavrosK
I saw this in another thread today, and I am _never_ NOT using it again:

<http://supergenpass.com/>

