(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
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?
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.
* 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.
“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-...
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.
On the 16 billion logins scale, it's just this.
Interesting use as "may have" as that would imply, mathematically speaking, that there are people who were impacted at least twice...
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.
Link to the 9 minute episode https://www.bbc.co.uk/programmes/p0lgv5vf
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.
Also, passkeys work fine on systems other than Windows/Apple
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
(WebAuth checks the domain before signing)
Voted down by amateurs who set their Web apps up this way. Killing the messenger won't secure your users' credentials.
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.
Like, "we solve your security issue provided you do business only with us".
That is neither "antifragile" nor resilient. It's just hype.
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)
Unless they were storing them all unencrypted lol.
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.
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
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…)
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!
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.
They can instead block all the passkeys, to be exact: WebAuthn credentials that are not rooted in hardware and don't have attestation.
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.
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.
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.
Edited: Sorry the last sentence was garbled nonsense originally, maybe it's the heat here. Or my brain is gradually deteriorating :/