43M passwords hacked in Last.fm breach
techcrunch.com
techcrunch.com
Most of your signups are not going to generate and store a secure password "just to try you out", as evidenced by the most common password here "123456". If you force people to signup to try your site/app, many (most?) of them are going to use a crap password. If you're _lucky_ that'll be 123456, and not their email/facebook/internet-banking password.
The answer isn't to try and force "good passwords" from users who don't care. Remember, by definition - they don't care.
We need to start trying to not require users to come up with passwords until they do care. Maybe just cookie me and let me tromp around as an unauthenticated user until I do something that needs me to set up a password-protected account. Maybe ask for my email and send me a login link that hooks me into my account/data without me setting a password (lets face it, your password security is going to fundamentally rely on the security of my email account, 'cause your "forgot password" story says you'll happily send a password rest link there, right?
I know Start-up-de-jour desperately needs "signed up user numbers" for their investor pitch, but that's not going to motivate me to stop using 123456 or password123 as a password when startupdejour.io demands I create an account just to look around.
I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive.
When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed.
There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world.
There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method.
Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.
Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
I'm pretty sure if any service less-technical than a CA authority starts pushing wide-spread user-driven in-browser certificate-based authentication, within days there'll be scammers and phishers faking the setup process to install untrustworthy ssl root certs so they can mitm Paypal/Facebook/everybody... How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate, and installing, say, the Charles Proxy ssl MITM cert?
Actually, even with current terrible UIs, there's a reasonably big difference between installing client certificate (there even used to be a <keygen> HTML tag for those - although it's unsurprisingly marked as "deprecated" now) and trusted CAs.
I tried getting one myself a few years ago, and I couldn't. The process was too obtuse and obscure for me to follow along the entire way.
Browser vendors have refused to touch that for years, so everything PKI-related has a cryptic UI hidden beneath 3+ clicks deep in the most obscure settings dialog areas. And some pieces are completely missing, like session state management (it's just like with HTTP auth - there are hacks to implement it, but they're hacks).
Another issue is, with current implementations not really fancying the idea of CA-less self-signed client certificates, so you'll most probably need a certificate-per-site approach. And with a ton of certificates (even if they all for the same public key), you'll need to automatically sync them to another devices somehow.
(The usual reasoning for not doing anything I saw was "no one uses this". Sure thing, given it's barely usable.)
Google / Facebook already know enough about services used, do we really want to transfer even more information their way?
Also, another trouble with this is the loss of anonymity.
There are very few places to register an email address without an SMS number. There are few places to get an SMS without a real name and address.
Yes, I'm sure there are places to get these things for someone willing to put in a lot of effort, but for everyone else, their email provider has their SMS, their SMS provider has their name and address.
So by requiring email as authentication, essentially every online identity comes back to your real name and address through a small number of hops.
It used to be possible to spin up a TOR session and interact with real services you would otherwise use. Between the crunch on anonymous email and cloudflare's endless captchas, TOR is increasingly useless for interacting with normal services.
This is a feature, not a bug. Unfortunately it turns out that many people are abusive when anonymous and use that to their advantage so anonymity has been curbed to keep control over that problem.
I'm building a service to solve this problem right now. It works already and I hope to make it live within the month, it just wants styling and polishing.
The idea is you sign up with just a username and password, no email address required. You pay with Bitcoin and can buy a mobile phone number, from a selection of countries, for ~$3/mo. You can then use the web interface to send and receive messages.
Email address in my profile - please get in touch if you're interested in learning more.
Don't need such service now, but I had accidental necessity in past few years.
(Also, please consider submitting it to HN when you go live.)
I will submit a Show HN. Thanks :)
- whatever solution we come up with needs enough market force to push adoption
- whoever gets to own "single sign on" owns the world. This is why there was so much backlash against Microsoft Passport all those years ago.
Personally I'd favour some sort of hardware token, and we're very slowly moving in that direction with U2F.
That doesn't mean applications are bothering to support them.
Actually, Facebook is ubiquitous for popular apps to the point it's often mandatory. (too bad for privacy :( )
Google App for business (and Microsoft to a less extent) have market shares among professionals but many SaaS and hosted applications cannot integrate with it at all.
The important bit about that is that the Last.fm/Audioscrobbler account credentials get typed directly into the third-party players - usually there's no browser involved in authentication, and in some cases the players will also be on a mobile device.
There's a definite incentive for passwords to be simple (if you're going to type them in on a mobile keyboard) and weak (because it's just music metadata).
So, a 'magic link' style of logging in might work here, but it would have to be complemented by an easy way of generating auth tokens for player apps - for instance, short one-time-use codes that expire quickly.
Copying and pasting links isn't that hard. Go to last.fm, generate OTP token/link, paste into Spotify. Done. I should have some easy way to identify authenticated apps under my account and kick them out, or reset all.
Not all of us use Web mail. And I might not want a link automagically opened there and then, under a browser.
This isn't even that greater of a concern; it currently is in 99% of cases the method for password reset anyhow.
That is already the case for the supermajority of people. They use one email account for everything and you can simply "Recover Password" on various services once you gain access to their email account.
Not many people purposefully use unique, individual email addresses for every single service they sign up for...
When they do, generally email for all of them ends up in the same account anyway.
So why are we pretending they do - and requiring them to give us email addresses and set up secure passwords?
(Especially when the "upgrade password storage to something more secure than plain text or MD5" is constantly being deprioritised below "add features X, Y, and Z that the product owner claims our next three investors on our pitch schedule have Tweeted about in the last month"... "We'll 100% definitely get to it once Series A comes in. for sure! Except perhaps for the 7 million 'legacy users' we signed up with plaintext passwords during our growth hacking private investor and seed round stages...")
What I want, is host my own security agent through which I can talk with any site. If I want to authenticate with site x, I simply point it to my security agent url and that's that. Open ID was/is an idea.
This approach will drastically lower the incentive for an attacker. Each attack will only get the data of one user, not millions.
Decentralized schemes are safer overall. Ideally you want something like what LastPass does: local credentials replicated on the network in encrypted form. This way you take away responsibility for safe storage from unreliable websites, but you don't place the whole burden on the user (as the data is replicated and locked by a single password).
I don't trust third parties, no matter who they are. Technology can be developed so that the burden on the user is reduced, but nodoby wants to go there, because after all companies do want to have as many data about the user as they can...
This happened with Yahoo's weird online publishing service thing. I don't even remember the name of it but one of my passwords was in their service and, at the time, I was using the same password everywhere. By the time I got the "Oh we got hacked" email, my twitter account was compromised as well as a few other sites. I didn't even remember signing up for their service let alone having an account.
I feel like some sort of regular clean out should also be standard. If I haven't looked at your site in 5 years, why would my account still be available? I know there are situations where that could cause problems but I'd rather lose an account for (random forum that I signed up for in 2008) than possibly have a breech that could, somehow, lead to my information getting stolen...
This drastically reduces the amount of valid logins from a dump that's even just a few days old.
2factor is simply not enough (though I still want it for important logins). Automatic password changing would be complimentary.
There isn't really a need for a standardized API it would make things easier but if 1password wanted it's not a very hard thing to do without it.
All you need is to do an HTTP request to change the password most sites allow that to be done in a single request, CSRF might be an issue but non single action forms are usually not protected or there is no need for that and there are ways to bypass CSRF also.
For a company like 1password it wouldn't be hard to build a request profile for say Alexa 500/1000 and automatically change the passwords once a breach hits, I have a similar setup of several scripts that update the password for various services I have by generating a random password in Keepass getting the old password sending the password request post and updating the Keepass entry.
You would benefit from open-sourcing them, so others could help you keep up with websites changing.
[1] https://blog.lastpass.com/2014/12/introducing-auto-password-...
If you get locked out of your password manager you are already fucked.
And in any case It doesn't prevent users from reseting a password manually directly on each site.
Enough said.
> The most popular password pulled from the Last.fm database was 123456. Seriously, it’s 2016 people
Sure, but the breach was in 2012 TechCrunch. Better article: http://www.leakedsource.com/blog/lastfm
0. rough heuristic: https://www.google.com/trends/explore?date=all&q=last.fm
Edit: If anyone wants to add me on last.fm here is my profile! http://www.last.fm/user/joer14
"In all other countries, listening to Last.fm Radio will soon require a subscription of €3.00 per month."
Then they killed radio.
I'm really sad to see it die, it was better at introducing me to new artists than any other service before or since, and the radio was brilliant.
Last year CBS decided the whippersnappers needed a redesign and took out around 80% of the features and put the site into a perpetual beta state.
Was mad about that as Last radio was my first choice for work listening.
The site was dated as they were frozen in 2008 - After CBS bought them there was one update very soon after then the site didn't change at all until last year. Minor updates and bug fixes only.
As for the update last year, pretty and vacant, doesn't bring back the things I loved about the site, but lets me see lots of pretty graphs of things I'm not interested in. I took a look at libre fm after that, but that's even more abandoned.
230K songs since 2004. http://www.last.fm/user/ryxxui
Top email domains :
1. hotmail.com 3. yahoo.com 4. aol.com
49th most used password: Blink182
Even in 2012, storing passwords unsalted (and probably even hashed just once) was considered bad practice. As was MD5.
Bad passwords being bad passwords also goes without saying. 123456 was never a good password.
I'm 100% sure it was known it was MD5 before, and I'm 100% sure I've seen pastebins with lots of successfully bruteforced hashes, because my password was among them.
Example: https://blog.lastpass.com/2012/06/in-case-you-missed-it-chan...
No it isn't.
> MD5 is seriously out of style
That's, err, one way of putting it.
> The most popular password pulled from the Last.fm database was 123456. L Seriously, it’s 2016 people
These accounts were made more than four years ago...
> use a platform like LastPass
Yeah about that... https://news.ycombinator.com/item?id=9721212
Poor reporting is poor. Why do I expect more from TechCrunch?
Also a better way to explain hashing algorithms to the lay person is to call them fingerprinting algorithms.
Another way to read this statement is that passwords simply doesn't work. We need something different. Something better.
And from the comments we find this:
> I am a bit confused. The article states that this happened in 2012, why is it posted today? Something happened in relation to this breach?
I think this also needs much better clarification. What has happened since 2012 which makes this newsworth now? And where is the LeakedSource report they cite but never link to? Where can I get more info?
This is very bad reporting.
(To be clear: I am not endorsing this scheme. It is superior to '123456', but it is still bone-headed.)
It doesn't really matter what it is. It matters that it's something you're not for a moment tempted to think of as a "real" password and that you would never dream of using for any account where a data leak would affect you, but merely as a "they're stupidly asking me for a password for an account I don't care about, so lets just give them this" token.
I'd lean towards agreeing with you that it's better to pick something else, but only to slightly reduce the inconvenience of someone messing with your account "just because".
Famous last words maybe, but then I'll just change my password?
I personally recommend 1password, because they haven't had vulnerability issues like LastPass and don't store passwords in their cloud, but they store it in "your" cloud, e.g. iCloud, Dropbox, and it works very well on iPhone. But at the minimum just using a separate password for everything is the best way to mitigate these kinds of issues.
Then the password manager could detect you're trying to register or log in and log you in itself, generating your password in the process. Why aren't logins machine-accessible yet?
Keepass does that pretty sure all the others also do.
But again what problem are you trying to solve? using password managers is easy as pie today including automating signup and generating passwords, most people do not use them.
Same thing happens with backups.
It's NOT easy. The interfaces are clunky. I have to pay to get some basic features like browser plugin. There's a lot of false positives (it suggests me sometimes to save a password even if the field is not for passwords.) Generating secure passwords is hard because some sites validate length and charset only serverside and the poor manager has the invalid password already saved. Some sites play tricks to discourage pasting passwords. More than once I was unable to log in LastPass's online vault because of an "temporary error".
All in all, it was horrible, ergonomy-wise. I don't wonder at all why people aren't using them.
The majority of open source products tend to have pretty shitty UI/UX =)
It took a while just to get up and running with the app/browser plugin/her own account, and now it's going to take a while for it to be part of her regular workflow.
The very first login I gave her (online banking) had such a bad interface 1Password couldn't auto-login.
So the next lesson was "how to work around bad website UIs, using a variety of non-intuitive menus and keyboard shortcuts".
We both use Dropbox to sync our vaults, so then I was talking to her about 2FA (pro/cons for text vs. Google Authenticator app), off-line recovery codes, an appropriate 1pass master password, etc.
There's no way she'd happen across a PW manager and love it. She's using it only because I want her to have access to all our online financials, all of which have long randomly-generated passwords.
I wish you luck! FWIW, I've found 1Password to be consistently better than LastPass.
I've been using lastpass for the past year or so, and I've had no real issues with it ergonomics-wise. I can't even think of any sites off the top of my head that have given false positives.
It does seem painfully slow and unresponsive sometimes though, which isn't ideal. It's slow enough to disrupt my flow more than just typing in the same password for every website.
It does cost to sync across to a mobile device, though.
https://news.ycombinator.com/item?id=5743057
Now that Persona is defunct and there is no privacy-respecting alternative in sight, perhaps we can finally acknowledge the truth that passwords are here to stay for the foreseeable future.
Also, using .well-known looks better than what I originally proposed (header or <meta> tag). For maximim compatibility with existing systems, there should be an option for this URL to respond with the actual login URL as well as any restrictions on the password format (length > 6, numbers > 1, symbols > 1, disallowed symbol list, etc.)
They have no clue or somehow good intentions always turn our horrible.
An old saying about countries that can't get together a government (like ironically Belgium!) - - it's the best for the people for having a country without the government because then they can't make more stupid laws.
Your password is not strong enough. New passwords must: Be at least six characters long Contain one or more numbers Include at least one of the following special characters: !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~, or a space
So password efZeLmur3ivio4t7 is not safe enough to be used by last.fm and they use md5 without salt to protect it?
Even though I have 1password setup, I would be so reluctant to create new passwords, I'm more willing to use OAuth whenever I can.
Ouch.
I guess on the bright side it won't be long before researchers have a new dataset of plaintext passwords.
Even still, I missed last.fm and probably a whole host of other ones that I'll never remember. Passwords are a goddamn nightmare.
As a new curious user of your new startup's website, I don't give a damn about being "secure". I've probably given you a fake name and a stupid password just so I can poke around and see if your site sucks any less than the other 5 or 6 new sites desperately craving my attention this morning.
If I can get in and look around without having to lie about my personal details - you're _way_ more likely to get a"proper password" and my real contact details if/when I decide I'm actually gonna add you the the list of "stuff I use" instead of "crap I signed up for once and never went back again" or "site I used a few times but none of my friends signed up so I stopped going there".
Mozilla Persona could have been another solution – just log in with your browser account – but that got killed.
And in the current web, I’m not sure something like that will ever happen, as the web is moving even more away from universal standards, and towards more and more closed walled gardens.
One thing we got dinged on was that we don't keep a password history, so that the user can't revert to their previous password. The tester's report said, "This, in turn, results in users utilizing a single password for a long period of time, which may result in password disclosure"
It seems to me that this is the opposite of the truth. If I'm keeping a password history, then in the event of a breach, there is that much more data that would leaking, potentially disclosing password data if we made a mistake in the rest of how we handle it (hashing, etc.). And while I'm not a crypto expert at all, it seems to me that if there's a list of salted, hashed passwords, then given that the salt is a constant per user, an attacker would have some leg up in discovering the original password if there were many samples that included the same salt.
If I want to minimize the data I can disclose about users, I ought to minimize the amount of data that I'm storing about them.
Just use a different salt for each password, not each user
Edit: You're probably right about everything else.
If they reuse passwords, then chances are you will expose them just as much if you don't force them to rotate passwords, when they end up putting their password into a scam site or run by people who store plain text.
And if you don't check for reuse, you are not forcing them to rotate passwords.
In the face of that, you can't do much better than to make it harder for them to keep reusing passwords on your site so at least a password leak elsewhere won't expose their account with you.
(And re-using the salt is a mistake; don't do that)
Having 12 strongly salted+hashed password strings is not going to help an attacker much compared to having 1, even if you use the same salt (though I've not doe the maths myself, you'll need to ask a cryto expert for actual risk figures).
You could of course use a different salt per stored password instead of per user, to mitigate this completely.
Remember that password reuse risk flows both ways: if they reuse the password in your application and your application is well written with regard to securely storing credentials, they may be reusing the same password in another application that is less secure so you are more at the mercy of the password data from elsewhere that is storing things plain.
Ah, looks like I was covered. But hey, now it's an even longer password with even higher entropy, so that's not a bad thing.
Be at least six characters long
Contain one or more numbers
Include at least one of the following special characters: !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~, or a space
Apparently they removed that option very recently and now you can only 'close' it, which hides it but doesn't ever deletes it. :/
Nothing wrong with the message per se, but has the site been defaced too?
What a terrible idea.
Fines for storing passwords insecurely and getting breached, sure. This is already handled by PCI/HIPAA, but could definitely stand to be improved. Prison time? There's no possible way that would end well.
Fines for "anyone whose password can be brute forced from one of these leaks"? So that means 80% of people out there would be given "substantial fines". Not going to happen.
How is that any different than giving speeding tickets? If you behave recklessly in a way that puts others at risk, you should have to make restitution to society.
But more generally, exposing your account credentials allows others to impersonate you and potentially scam others, expose the data of others, etc. In the case of Last.fm there obviously isn't a ton of potential for abuse directly, other than maybe firing off fake song plays to pocket the royalties, but the potential for greater harm exists in the general case. E.g. consider the enormous percentage of credit card transactions that are fraudulent, largely because of scammers using PII that's stolen in these large scale hacks. That absolutely effects the fees and interest rates for everyone else using banks in any way, so even if your own identity isn't stolen you're absolutely still affected.
And even in some hypothetical scenario where the only person harmed would be the person using the weak password, there is still precedent for regulation because we have laws requiring people to wear bike helmets, preventing kids from smoking, etc.
1. User signs up for a web service, uses weak password.
2. Web service recklessly stores passwords/hashes in an easily crackable way.
3. Someone hacks the web service, steals usernames and passwords/hashes, then leaks the data.
4. Someone potentially uses the leaked credentials/user information to impersonate user, commits identity theft, fraud etc.
5. User receives a "substantial fine" for using a weak password (like 96% of the users of this online music service).
I had written a more long-winded response, but it probably suffice to say that there are major issues/contradictions/implications of what you're proposing. Like how would you enforce it, should law enforcement only rely on data theft/leaks, or should they have direct access to all user databases for online services? How would they prove the integrity of the data leaks? How would you prove that the password is reused, and how'd determine the size of the fine? Does it matter if the password is strong, but reused and one of those services stores it in plain text and is hacked? Would it be legal to use a weak password for a service if the hashing algorithm is strong, or just as long as the service isn't hacked and the data leaked?
verify(candidate, storedEntry) has to run in a time reasonable for a web service to handle, which means that 123456 is still going to get tried against all the accounts in a reasonable time.
Most jurisdictions already have security breach notification laws. If you're already required to report data loss to customers and/or the government, then at that point I don't think it's unreasonable to require companies to provide a copy of any leaked credentials since they should all be deactivated anyway.
> How would you prove that the password is reused, and how'd determine the size of the fine?
If companies were required to turn over credentials that had been breached, then this would be determined from the entire set of breached credentials.
> Does it matter if the password is strong, but reused and one of those services stores it in plain text and is hacked?
Sure, that's exactly why you're not supposed to ever reuse passwords even if they're strong.
> Would it be legal to use a weak password for a service if the hashing algorithm is strong, or just as long as the service isn't hacked and the data leaked?
I think there should be some minimum entropy level that's required regardless of the hashing algorithm. E.g. given that passwords can be automatically generated and stored, there is zero reason ever to use a password that's less than 30 characters of completely random characters.
> what you're suggesting requires at least two other crimes to be committed
The fact that these crimes are interconnected is why such a law is needed in the first place. And all these attacks are automated, so if you're reusing your last.fm password on Facebook and it takes ten minutes to brute force your last.fm password, then your Facebook account is going to potentially be pwned in ten minutes and 1 second.
If there were some benefit to having weak passwords then that would be one thing, but the way I see it it's just people creating a national security risk out of pure laziness.
Isn't that rather like fining someone for being too weak to fight back when assaulted?
If anything, the whole thing goes under radar.