Billions of login credentials have been leaked online
apnews.comDubious origin, lots of other copies:
(17 points) https://news.ycombinator.com/item?id=44316114
(30 points, 3 comments) https://news.ycombinator.com/item?id=44318192
(12 points, 4 comments) https://news.ycombinator.com/item?id=44320243
(26 points, 15 comments) https://news.ycombinator.com/item?id=44321381
(9 points, 2 comments) https://news.ycombinator.com/item?id=44322204
(11 points, 2 comments) https://news.ycombinator.com/item?id=44322288
(10 points, 3 comments) https://news.ycombinator.com/item?id=44322588
(10 points, 2 comments) https://news.ycombinator.com/item?id=44328038
There is no world where AP is dubious and Forbes deserves the click
AP is reporting what others are reporting. What's dubious is the original reporting.
Pretty much sums up the misinformation machine world we live in today.
> According to a report published this week, Cybernews researchers have recently discovered 30 exposed datasets that each contain a vast amount of login information — amounting to a total of 16 billion compromised credentials. That includes user passwords for a range of popular platforms including Google, Facebook and Apple.
Can someone more knowledgeable than me explain how my passwords could have been leaked from Google or Apple? Or is this just bad reporting?
It is my understanding that neither Google nor Apple have my passwords stored, and any password service they have like the iCloud keychain would presumably be encrypted. What am I missing?
Others have explained what's really going on here, but I want to take a moment to address this idea that they don't "have my passwords" because that's illuminating too.
In a very real sense most of these systems, almost everything on the web today, do have your password, though that wasn't necessarily the direct cause of the problem here.
Passwords in this context are a shared secret. You remember your Google password is hunter2, you send that password to Google's web server to log in, they check, yup, hunter2 is the password, OK.
For 50+ years we've had these slightly goofy strategies with these shared secrets, which if you have a good password (so, not hunter2) and Google implement the strategy well, mean that at rest they don't really know your password. But still every single time you authenticate, you are sending them your password, and when that happens you both know what it is† - this means for example they could accidentally publish it, record it to a log, or anything else.
For less time, but still decades, we've known how to build an Augmented PAKE. With this technology, you can prove to (say) Google that you know some password, and then later, that you still know the same password, yet Google never learns what the password is - which means that even if they really wanted to they can't tell anybody else - all they can do is check that you still know your password, which is in fact the thing we actually wanted.
Nevertheless, here we are in 2025, and judging from previous times I've explained this, HN will insist that the schemes which haven't worked are a great idea and there's no reason to use an Augmented PAKE.
† As does anybody who can read the messages, which in 2025 is usually nobody else, but say 10-20 years ago was usually anybody on the path, e.g. your ISP.
We have not had augmented PAKEs that were widely trusted by the cryptographic engineering community for decades. OPAQUE was 2018. The adoption you're looking for hasn't happened for a bunch of reasons, including:
* The industry's (reasonable) emphasis on moving people away from passwords altogether, and towards phishing-proof authentication.
* The fact that we'd have to do new underlying protocol work to meaningfully get the benefit you're talking about --- you can't just do it in Javascript, because you're talking about "server-proofing" logins, a threat model that presumes the attacker controls the server's login flow.
* Just the baseline fact that "losing passwords directly from Apple and Google and Meta authentication servers" hasn't been a driver of account takeovers, and you will never get PAKE adoption from the kinds of providers who do drive these incidents.
PAKEs are just a technology cryptography nerds fall in love with and want to find use cases for. I like them too! Build more things like Magic Wormhole. Don't get grumpy when the entire web doesn't wrap itself around them.
My Google account is indeed protected with Yubikeys and so on. Years after I bought my first Security Key, I can name all the places I use it, whereas if I type 'pass' the list goes on for several screens.
But while it's true that OPAQUE is what you might choose today, SRP is much older. We didn't have AES in 1995, we certainly didn't have a workable AEAD but instead of waiting for 21st century technology Netscape shipped SSL - very flawed but points in the correct direction.
The web actually went backwards in a sense. HTTP is designed with an authentication layer, but it's not up to the task for modern systems so nobody uses it in user facing software, only some APIs.
This feels like a theme - we can have better things, improvement is possible. "Oh well, it's never getting any better than this" isn't quite as stupid as "Nothing could be worse" (followed often very shortly by the discovery that you've underestimated how bad it could get e.g. electing the "outsider" and then electing him against now he's a felon) but it's still a mistake.
As you may know I have a habit of re-reading old stuff I wrote, one of the classics is from when Let's Encrypt launched and I'm explaining to Peter Gutmann about ACME. Peter's take is that we shouldn't make these protocols at all, they're a waste of time, and if we want one SCEP already exists. As you know, ACME has been an enormous success, but at the time this was not obvious. Peter was assuming that it's never getting any better, but it actually got almost unrecognisably better and quite quickly.
Right. I like SRP. I've implemented it many times. It's also a personal favorite because it coughs up amazingly good vulnerabilities (it's not often a dumb crypto implementation bug gets you a full auth bypass).
But cryptographers did not generally like SRP. Lots of cryptographers had misgivings about it. It is not surprising to me that SRP didn't get usefully baked into the web.
This "HTTP is designed with an authentication layer" stuff is a very old argument on HN. There are two sides to it. The other side is: baking stuff directly into the protocol makes us path-dependent on what we decide to add (see: every protocol ever designed), and if we were path dependent on 2002-era cryptography, that would be a very bad thing. Authentication is a complicated problem and people's needs differ.
I respect the take, the same way I enjoy reading Gutmann even though I agree with only like 50% of what he says.
Again I'm not here to praise SRP, though I will mention that when I think of you and and dumb crypto for a full bypass I always think of your surprise that Microsoft shipped a broken ECC implementation in Windows some years back. It's hard to dig a pit of success deep enough that everybody falls in, and that's why I like systems where we don't tell people things they don't need in the first place.
We didn't end up path dependant on RC4 for example, even though it's in SSLv2. RC4 is similar to SRP in some ways because nobody was ever comfortable with it but people kept trying to patch the known issues until eventually we gave up on it entirely.
Yes, we did! RC4 is a great example of what I'm talking about. It's a cipher nobody had any business ever using, and we were using it well into the 2010s, despite the fact that the (comically simple) underlying vulnerabilities in it were known in the 1990s.
How is RC4 a great example? Obviously with hindsight you'd choose something different, but in the mid-1990s there wasn't a lot of good options - in your alternate history do we just hope DES (which we know has a NOBUS for the US government) is OK forever? Do we go without SSL altogether ? What's the plan ?
I don't understand. Why did we need RC4 for SSL? Most SSL and TLS connections just used CBC-mode.
CBC mode of what ? IDEA maybe ? Are you here to go to bat for IDEA because it's in better shape than RC4 (likely because nobody cares) ?
Even DES-EDE is better than RC4.
3DES? I guess. People banged on it a lot more than IDEA, which is good, even on your worst days banging on things has potential to shake loose anything poorly put together. But as a "path dependency" I think it might teach an even worse lesson than RC4 did.
Edited: Sorry the last sentence was garbled nonsense originally, maybe it's the heat here. Or my brain is gradually deteriorating :/
I don't see how that could be the case. The major problem with DES-EDE is shared by all the 8-byte-block ciphers, and the fix was simply to upgrade. The problem with RC4 is much more fundamental.
We also have passkeys now too.
Bad reporting.
“There was no centralized data breach at any of these companies,” Diachenko said when I asked him to clarify whether any of the datasets actually came from Facebook, Google, or Apple.
Bob Diachenko, a Cybernews contributor, cybersecurity researcher, and owner of SecurityDiscovery.com, is behind this recent major discovery.
https://cybernews.com/security/billions-credentials-exposed-...
>Can someone more knowledgeable than me explain how my passwords could have been leaked from Google or Apple? Or is this just bad reporting?
A lot of this data, probably 95% + is from mass leaks from hacked sites. Hacked some non-google non-apple site, maybe 3 years ago, maybe 10.
Your login to that site is your email (@gmail.com) so there you go. your email may be in there several times with different passwords, corresponding to several hacked sites. if on whatever site, dropbox (which had been hacked this way), your dropbox login is same as google login.. there you go, that's how they did it.
some hacked sites have your password in plaintext, some with a weak hash algorithm which easily got reversed, either way, outcome is your password is known
rest of the passwords are from something now becoming more popular which are "stealer logs" - basically malware that's taking screenshots, scanning for bitcoin wallets, keylogging credentials, steam info etc, and logging it all. the stealer type systems have caught me eye in the past few years, the 2020s, but I'm sure that community existed prior, and certainly this type of software goes at least as far back as the '90s.
Keyloggers, people reusing passwords
Also browser extensions.
>people reusing passwords
On the 16 billion logins scale, it's just this.
The password to your Google or Apple account?
Will this make its way to haveibeenpwned or other services?
> Sixteen billion is roughly double the amount of people on Earth today, signaling that impacted consumers may have had credentials for more than one account leaked
Interesting use as "may have" as that would imply, mathematically speaking, that there are people who were impacted at least twice...
The subject of that sentence was consumers. Individual consumers 'may have' multiple credentials leaked
The list might also span a large time period and contain multiple versions of a user's credentials.
A common dark web strategy is just to re-bundle old password leaks to sell to white hats looking to investigate such leaks. Which is an amusing scam and one of the problems with trusting anything on the dark web.
Also, dead people had passwords.
To be fair, we really have no idea how many people are on Earth today. Eight billion is our best estimate, but we also recognize that many of the sources used are undercounted to some degree. What's hard to determine to what degree that might be. A somewhat recent article in Popular Mechanics [https://www.popularmechanics.com/science/environment/a642223...] suggests that recent data may indicate that the estimates are way off... But who knows?
Granted, any discrepancy is probably not on the order of reaching 16 billion. An additional billion uncounted would be incredibly surprising. But also, the accounts don't necessarily equate to people still on this earth and maybe don't equate to people at all. Robots have been known to create accounts too.
A co-author of the study you refer to was recently on the UK BBC podcast More or Less, debunking much of the press coverage of his study, specifically the headline of vast global underestimation. Rather, the study found rural distribution estimates may be inaccurate, not total population.
Link to the 9 minute episode https://www.bbc.co.uk/programmes/p0lgv5vf
Can we be done with passwords yet? I see far too many sites offering a passkey option
Sure, here's my public ssh key: public.swiley.net/id_rsa.pub I've been using this with everything important and was just waiting for everyone else to realize it was better.
Oh no wait, you wanted some retarded Windows/Apple thing that needs biometrics, locks everything to your pay for service/hardware, and has a worse security model.
Nevermind just use a password.
I agree that passkeys are overly complicated, but they are in no way a worse security model than passwords. That is ludicrous. The password security model is an incredibly low bar to clear if you want better security.
Also, passkeys work fine on systems other than Windows/Apple
If you have a password manager, what is the point of passkeys?
I was having this discussion earlier with a friend and we could not think of a compelling case. They seem less portable and harder to use on multiple devices or new devices. The only thing I could think of was protection against copied sites, but most users using password managers also block ads which should block most scam sites and password managers just need to have more messaging for if you try to fill in credentials on a site that is different from the site information saved with the password
Malicious website that looks like your bank can't get you to tell it your passkey, but you can type in your password.
(WebAuth checks the domain before signing)
Our digital identities have become more valuable than most physical property but I still don't see society taking it seriously. People like my grandmother constantly shedding information to any pop-up that comes her way. Our governments not prioritizing this threat as a true top priority and properly funding it and taking action on it. (911 for digital crime maybe?) People not seeing others and properly shaming them and turning them in for digital crime like we would do if we saw property crime, etc etc. The scale of something like this is absurd, even if it is a lot of re-packaged data. The amount of time people will be dealing with the fall-out from just this one incident can likely be measured in thousands of people years. Or, put another way, this is on par with the impact of mass murder in term of lives altered. As a society we really need to make changes in our laws and behavior to really internalize how massive a problem this is before we can even start to address it.
This is a good reminder that forcing people to use an E-mail address as a user ID is a stupid and dangerous policy.
Voted down by amateurs who set their Web apps up this way. Killing the messenger won't secure your users' credentials.
The email acts as an implicit second factor. But in any case security is a losing battle anyway. We should assume everything is compromised in the long term
As if users wouldn't just use the same username everywhere. So now besides telling them to use different passwords for every website, you also need to tell them to use different usernames.
But you can't use the same username everywhere, for example doing a Google search of my username shows accounts on other sites that are not related to me. Doing a search for your username suggests that it is also likely taken on numerous other sites, including a rock-band named FoxyGen that I'm fairly confident you are not a member of.
Well, yeah, the same way you can't use the same password because some websites have weird rules about password length and characters. Doesn't change the fact that you will be able to use the same username in MOST websites, given you don't have a super common username. The only solution to this problem is a password manager, which most people won't adopt anyway.
So what? At worst, it's no worse. But by default, it's already way better.
Why? Because all of our E-mail addresses are on thousands of spammers' lists. So if you hammer that list with a dictionary of popular passwords, you're going to get a bunch of compromised accounts right there.
But even worse: When you force non-tech-savvy people to use their E-mail address as their ID, many are going to think they need to use their E-mail password as well. So now if one poorly-run site suffers a data breach, all of its users' E-mail addresses AND passwords are out there. Identity theft ahoy.
Not to mention the loss of people's accounts when they change E-mail addresses; When Apple started requiring that Apple IDs be E-mail addresses, it created a massive problem of people having purchases scattered across multiple accounts because they'd create a new one when their E-mail address changed.
After the outcry, Apple huffily declared that it wasn't going to let people consolidate their accounts.
But back to the point: Allowing people to create a proper user ID as free-form text doesn't preclude them from using their E-mail address if they insist on doing so. But they should be encouraged not to.
the article mentioned passkeys as a solution but imho is only a path towards vendor lock-in.
Like, "we solve your security issue provided you do business only with us".
That is neither "antifragile" nor resilient. It's just hype.
I have my passkeys in 1password and they work fine. One key for each service, I don't see the difference to normal passwords in terms of lock-in
Look up passkey provider attestation. Services can't block your password manager, but they can block your passkey manager. It was used to threaten the KeePassXC devs into removing cleartext passkey exports.
Services manage to "block" my password manager all the time by confusing it to the point where I have to copy and paste my password manually. It's a huge security risk (because where am I actually pasting this password?), and super frustrating.
EDIT: I'm not saying that the passkey situation is great, but it's not worse than passwords. It has so many benefits over passwords that we should absolutely not let perfection be the enemy of good enough!
That's incorrect. There is nothing in a passkey that identifies it as a "key from KeePassXC", so it can't be blocked.
BitWarden exports passkeys just fine as cleartext, or to be precise as a file encrypted by the user-specified passphrase. So you can then decrypt it at your leisure.
While I don't agree with the grandparent's fears, you're only half correct: The server can mandate that you use an authenticator from X company, so some sites might block KeepassXC, even if they don't block a specific key.
There is no specific attribution in Passkeys, there's AAGUID but it's allowed to be all-zero. So they actually can't block passkeys _from_ KeypassXC.
They can instead block all the passkeys, to be exact: WebAuthn credentials that are not rooted in hardware and don't have attestation.
I'm probably missing something, so would be great to get a ELI5 for this.
How does storing passkeys in a password manager materially differ from the very long/strong passwords I'm already storing in my password manager? (and it's matching against the domain around autofill etc)
Passwords are a shared secret. You know it, and the website you are logging into knows it. If the website leaks it, someone else can log in as you.
Passkeys are a private key/public key pair. You give the public key to a website, but you don't share the private key with anyone. To log into the website, you encrypt a short message with the private key, and they can use the public key to decrypt it. If they leak the public key, it doesn't matter. Nobody can use it to log into the website. Only the private key can do that.
Also, there is a standard way of logging into a website with a passkey. The password manager can easily do it on every website. With passwords, every website is a little different. Your password manager can log in easily on some websites, and on others it can't and you need to copy and paste your password from the password manager to the website.
Besides being inconvenient, people have been able to write code that tricks password managers into thinking they are sending your password to the correct website when they are actually sending it to bad guys. Similarly, humans can be tricked into copying and pasting the password to the wrong place, giving it to bad guys. That leaks the important shared secret!
If someone tricks your password manager in a similar manner with passkeys (which is much more difficult because of the standard way password managers and websites communicate), all they get is a message encrypted with your private key. Maybe this could be used to log onto a website one time if they are very clever, but they do not get your private key which could be used to impersonate you many many times like a leaked password would.
Can't be phished. With a normal password manager, user error could lead to copying credentials and pasting out to a phishing page which is irrelevant with passkeys
Autofill is a good point but it doesn't help your parent who thinks the thing is broken so they have to do it manually, rather than realising it's a phish
A passkey never exposes a secret to the website, so neither malicious scripts (e.g. via ad networks or analytics “partners”) nor malicious browser extensions can scrape the password.
Plus passkeys are inherently phishing resistant, and don’t rely on the end user being wary when autofill don’t work. Autofill doesn’t work a lot, due to broken sites blocking paste as well as stupid sites that have you enter your creds to into multiple domains. (Yes, I’m looking at you, United Airlines…)
How?
2FA makes this a non-issue, no? You will get notificaton if someone failed to log in.
Not even necessary. Salted hashes are enough, assuming you used a strong password.
it looks like a lot of these are from key loggers not from database breaches, so salted hashes, while nice, solve a different problem.
I didn't see that, yikes. That's one hell of a breach then.
Yeah assuming you have a billion encrypted passwords what are you even gonna do? You could try to brute force and maybe get a bunch of common/weak ones but as long as your password is like 8+ chars and fairly unique you probably wont be a target.
Unless they were storing them all unencrypted lol.