Change your Last.fm password
thenextweb.com
thenextweb.com
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.
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.
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.
It's not that easy to get rid of either, the banks have to support internal applications that expect things in those formats, as well as all the unofficial apps that plug in via messaging systems and may not be aware of the other app from either end.
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.
I entered the password from the xkcd comic in this web site: http://rumkin.com/tools/password/passchk.php
And got an entropy of 51.8 bits.
Long passwords are great (especially if one is using a password manager), but not many places accept them.
I imagine the calculation goes something like this:
1/50000 Likelihood of a particular uncommon word
1/8 Substitute up to three letters for numbers
1/2 Initial capital or initial lowercase
1/32 Add a punctuation character at the end
1/10 Add a digit at the end
1/2 Possibly swap punctuation and digit at the end
----------------------------------------------------------
1/512000000 Resulting probability
-28.93157 log2(1/512000000) -- number of bits of entropy
For my passwords, I use 8 character random strings so hopefully I am a little safer. Although, as I'm learning from all of these password leak debacles, you are only as secure as the systems using those passwords.
Something even more ridiculous Chase does is assign a default pin of '3210' to checking accounts.
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...
o Your German bank may have your password stored in an Utimaco/Sophos Hardware-attack-resistant keysafe, not hanging out in some linux hash file.
o If they lock you out after 3 tries, and the keyspace is [a-zA-Z0-9] - that's 916,132,832 combination, and only three attempts to get it right before being locked out.
On the surface, it sounds much less secure, but, depending on their procedures and hardware, it might be significantly more secure than a 9 character password that goes into a hash file that is software accessible.
Of course - better case - is a Hardware key safe that lets me store my 30 character 1password random 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!
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.
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.
Fundamental flaw with that- you can't change your fingerprint if/when it is compromised.
[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.
Although the real entropy of thumbprint images is likely to be much smaller, considering that they share many simliar pixels... but it's still unimaginably huge compared to a short alphanumeric password.
Could something like this be made to work? Work in the sense that a variety of cameras could read the same "password"? I guess QR codes have a fair bit of redundancy built-in...
I've been very satisfied with 1Password and I can't imagine going back to not using it.
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.
Everything else is 16char upper/lower/digits/punctuation randomly generated by 1Password (except where I need t back that down for sites/services that wont accept that length/charset).
I've also got my random 16char AppleID password in my head, since I end up entering that often enough into place 1Password can't autofill.
I _think_ that's "paranoid enough" at least for now.
One thing I'd like 1Password to do, is bug me about passwords that haven't been changed in some (configurable per login) time. I'm pretty sure in 2 years (or less) I'm unlikely to consider 16char passwords "long enough".
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.
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.
# 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.
http://blog.linkedin.com/2012/06/06/linkedin-member-password...
Does this mean before this leak, they didn't hash/salt passwords?
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.
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.
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.
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.
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.
You're scrobbling songs during your whole work day, right? I disable it at work, since I don't pay much attention and end up with lots of plays I don't care much about.
(edit: my average is really 10 songs/day!).
Show HN: pclark listens to Miley Cyrus, A LOT.
Do you use the same password/username combination somewhere else? If not, good for you. You're kind of a rare person.
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.
A long time ago, I signed up to PerkMonks for some unimportant reason. Since it was unimportant then (and still is now) I used my then-standard "throwaway login". Sometime later, and before it became "a thing", I signed up for this new "microblgging service" using my "throwaway login" - it was called Twitter - nobody much had heard of it back then. Fastforward 3 years or so… Twitter had become, while not _important_, at least a place where I consider my personal reputation is important. Shortly after the PerkMonks user database got exposed (with it's cleartext passwords! facepalm!), I got an early morning text message from a friend "Acai berry spam from your Twitter account! Ha ha!" (Thanks Colin… For both the heads-up and the deserved ridicule)
If you're using the same "throwaway" credentials in a bunch of places you consider "unimportant" - make sure you upgrade those to properly secure credentials when the importance of those places changes.
Or better still, get 1Password/KeyPass/LastPass/WhatEver and stop doing that…
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).
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.
EDIT: The developer who apparently implemented the password hashing replied to me on Twitter: https://twitter.com/russss/status/210783976879693824
Check out the twerps at @CrackMeIfYouCan.
This means next leak will be one million CRC32 password hashes?
Or maybe LM hashes. Or crypt on old /etc/password files
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.
Totally true. One service of a rather large European bank stores passwords in plain text. It's just waiting to be exploited.
That, and Facebook supports two factor authentication and (hopefully) isn't leaving their pw db as unsalted md5...
The problem, of course, is a lot of sites still don't support OpenID.
Good security assumes that everything can and will be compromised and provides defence in depth. Client certs do little to help.
Private key files pose a challenge, absolutely. But is it so much worse than having every company Jack store passwords in $non_crypto_hash_system?
(begin-rumination....
Right now, compromise risk for credentials typically lies on the companies. They frequently fail in protecting these credentials. However, your credentials are - inadvertently - distributed out between multiple companies. When one goes down, the other credentials are considerably less affected.
(More so if you've been bad and used the same password everywhere).
Examining a local store, we centralize risk onto the local desktop. Suppose that in order to log into the user's central system, the user had to provide a password. (Example: gpg-agent). Then, to log into a remote system (web, ssh, etc), the user's credentials get passed into the remote system via some well-known private/public authentication scheme.
Points of failure here:
- user forgets own password. All credentials are lost until they manage to get reauthenticated into the system.
- Malware hacks the user's keystore and uploads private keys to $malware_database. Case 1: in-memory hack. Case 2: hacks system database.
- Case 3-ish. Malware injects dialog requesting system password and gullible user enters it. Upload commences...
I am sure other scenarios can be imagined. In these scenarios, the risk is shifted from the company onto the user (and the key storage engineers).
I can imagine that password forgetting would be heniously problematic and cause PR disasters: many people don't like to take responsibility)
This is not the best possible solution but I can't see how it would be worse than a compromised salt/bcrypt hash.
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.
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.
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 :)
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.
[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.
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.
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.
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?
_______
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.
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)
Though older APIs they're still used by many older or infrequently updated clients, such as hardware devices with sold with Last.fm integration.
Unfortunately, the longer you've been around the more likely you are to develop dependencies that make it more difficult to upgrade your password hashing.
A new site can do whatever it wants with password hashing, but it becomes harder for older sites with more legacy dependencies to make that kind of change and Last.fm has been around for almost 10 years.
This isn't to say "MD5 is cool, don't worry", but to try and illustrate some of the reasons behind this.
You specify an order of the hash algorithms, putting the one you want first. Switching to bcrypt for me was just a matter of moving it up a few lines in a list.
The password field can probably stay the same length, since it is a hash value anyway. I'm assuming you have a second field that stores the hash algorithm used. When it logs you in, it uses the current algorithm to authenticate you. Then if that technique isn't first on your list, it creates a new, salted hash, and stores both that and the new hash type in the database. Nice and slick.
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.
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.
To delete your Last.fm account, go to the "Data" tab in settings. Click on "Delete entire account for user".