43M passwords hacked in Last.fm breach

Probably getting downvoted because these comments are common and don't make any suggestions on how to get rid of passwords.

Yes, we could argue that user should use more secure password, but on the other hand, I always wonder why startups these days are still busy rolling out their own custom account management than leveraging OAuth or hosted solution like Auth0. Seriously, in how many cases do we have a feature that is so unique that is not available via these alternative solutions?

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.

Got it, I certainly disagree and don't think the 41.000.000 last.fm users (whose passwords were cracked in two hours) should receive a substantial fine. I don't think there's a whole lot of precedence for this type of legislation either; what you're suggesting requires at least two other crimes to be committed by someone else (before someone else would potentially be at risk due to the user's bad password choice) - in addition to recklessness on behalf of the service provider (which also may be regulated and/or illegal under PCI/HIPAA/etc as grandparent points out). In other words:

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?

It's really a shame that we haven't solved this problem yet as an industry.

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.

> Sure, but the breach was in 2012

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.