Apple silently uploads your passwords and keeps them
lapcatsoftware.com
lapcatsoftware.com
The good news is that the device is owned by me and under my control. However, since it's just a test machine with no personal data—or so I believed—it's less protected than my other devices. For example, it has a weak login password, no Filevault, and no biometrics (Mac mini).
In general, the presence of my passwords in the cloud is an unwanted and unnecessary liability for me. I understand that for other people, cloud storage is a benefit, and I don't wish to deprive them of that choice. Nonethless, Apple deprived me of a choice in this case.
Settings -> Apple ID -> iCloud -> iCloud Passwords & Keychain -> Sync this Mac
In general though having a weak password on a device logged in to iCloud is a bad idea.
You clearly didn't even read the article. The whole point was that Apple silently toggled this on without my knowledge or consent.
It's not the happy path though. We need a tech a company that prioritizes local-first designs.
Firefox does not, but it sure prompts the hell out of you to do so.
Also, chromebooks require such a sign-in as well, and I'll bet they enable that syncing by default as well.
Singling out Apple here is kinda silly when they're encrypted (if you don't trust Apple to tell the truth there, running their OS at all is risky), and when the behavior is that which we'd expect.
And at the end of the day, using Apple's password manager is mostly (exceptions including wifi passwords) optional.
The blog post is about how it was off and then got silently toggled on.
> Singling out Apple here
I'm not a journalist covering tech companies. I'm an Apple user complaining about something that happened on my own Apple devices. It's silly to characterize that as "singling out Apple".
I do use Chrome, though, and it never silently switched that toggle back on. If it did, I'd definitely blog about that.
Of course not, I come here for the comments.
This seems to be the industry trend with these remotely managed machines, like Apple or Windows PCs. The update mechanism, for better or worse, takes power from the user and assigns it back to the manufacturer / service provider. It's something that the software world would have considered a Trojan horse some 20 years ago, an extension of control to the end users machine, for someone other than the end user themselves.
I'm not sure where I'm going with this. What's for sure is that the IT zeitgeist really changed over the decades.
If you're curious, it's because the W11 Bluetooth stack is somehow even more broken than W10. Our entirely standard Bluetooth widget can't communicate with W11 PCs and there's really no good way to discover how or why. Bluetooth support is so bad in Windows that I've been assigned to start porting all our software over to Linux. I could go on for hours over this. Windows is so bad.
Pray they don’t finish the job. </Vader>
Why are you being repeatedly, needlessly pedantic? Everyone knows what I meant (including you, who chose to misinterpret). Your other comment was also pointless: "that's still choosing Mac over Linux and every day you continue to make that choice." https://news.ycombinator.com/item?id=42016888
You can play with your own ultra-strict definitions of "own" and "choose", but please do it in your own mind, and don't pester us with them in these comments. It adds absolutely nothing to the conversation.
I think that it adds a ton to the conversation to note that using Apple software is a choice. Continuing to use Apple software, even after Apple upload all your passwords to iCloud, is a choice. Not switching to alternatives is a choice.
Those may all be defensible choices. They may even be correct. But they’re still choices.
In your particular case, given that you appear to support yourself by selling iOS apps, it probably makes sense to keep using Apple devices. Retraining to write software running on Linux would be work. And few Linux users would buy software anyway.
But if you ever get tired of using OSes you can’t control on devices you can’t control, and want to write software to do what you want, you might want to come on over to Linux. It’s pretty fun!
No, it's not what the word meant. What a word means depends on context. If I had simply said, "The good news is that the device was in my home under my observation", then the commenter "mcsniff" would have no opportunity to go off on a rant about "ownership" and "control". Or maybe you're going to argue pedantically that it's not "my" home, because I'm a renter? Or would you argue with someone with a mortgage that it's not "your" home, it's the bank's home? That's just pointless pedantry that clarifies nothing and benefits nobody.
> I think that it adds a ton to the conversation to note that using Apple software is a choice. Continuing to use Apple software, even after Apple upload all your passwords to iCloud, is a choice. Not switching to alternatives is a choice.
Everything is a choice. Therefore it's a tautology and adds zero to the conversation. Your comment was a choice. My comment is a choice. Choice choice choice choice. So what?
>The only way to see the contents of iCloud Keychain is on an Apple device with iCloud Keychain enabled. You can't even see anything on the icloud.com website.
FYI this is because of all contents of iCloud Keychain are end-to-end encrypted, such that only your devices are able to decrypt the data. Apple’s servers do not have access to the contents of a user’s iCloud Keychain.
You might find this article interesting:
https://support.apple.com/guide/security/icloud-keychain-sec...
Also the second part of this Blackhat talk, titled “Synchronizing Secrets” is very interesting and details the design and security architecture of iCloud Keychain: https://youtu.be/BLGFriOKz6U
The relevant part of the talk starts at 22:40.
[*] They consider it a feature; you may not.
[1] https://support.apple.com/guide/security/secure-icloud-keych...
[2] https://support.apple.com/guide/security/escrow-security-for...
The big question here is whether there’s a reproducible way that the opt-in changes. iCloud Keychain has robust end to end encryption but it still needs to inform the user.
They offer no option to delete your passwords from the Cloud once there?
If that's indeed how they all/always work, we shouldn't just Stockholm-syndrome accept it!
Seems pretty trivial to download the icloud windows client (which has password manager support), and modify/delete the passwords there?
Does it matter tho. Like in general internet, once something is posted, it will not disappear with certainty. We can never be certain that there is a copy of the encrypted password on some log file when we have no visibility into that sytem. Since it is encrypted, it passes the regulation checks.
That is just a UI bug if passwords keep coming back in the cloud/you still see them. Unless there is a system in place that can transparently verify that indeed, the passwords are deleted, does it matter?
This is a pretty lame windmill to tilt at.
They really want to avoid the risk from anyone inside the company having access to your passwords and then doing anything with them.
Compare the consequences for a large company vs an individual.
For the individual, if caught, a debilitating fine and, depending upon damages, jail time. Probable end of career, if related.
In short, life changing.
For the company, possible fine almost certainly less than the revenue made. Small chance of larger civil suits, with legal costs and possible judgments. Depending upon visibility, perhaps some additional PR spend. Even if the sum total cost is greater than the associated revenue, those costs can be used to offset tax liability.
In short, low risk of existential threat, or even actual financial loss -- just reduced profits.
Maybe a plunge protection stock-price guarantee.
Or NOT.
Apple on the other hand would see your bank balance as a rounding error to a rounding error, but could easily lose a billion dollar from bad publicity that’s what’s balancing vs any financial upsides. Further, doing it once doesn’t move the needle it needs massive scale and thus massive risks to be worth anything to them.
It is essentially about the trust. You either trust that they don't misuse the cloud-uploaded passwords or not. If you cannot trust that, you cannot trust the whole ecosystem as the same entity controls it and can misuse it in any imaginable way.
So essentially, the issue of deletion is just about the visibility in the UI, if we trust their claim about the end-to-end encryption.
You can absolutely to a high degree protect and store data, including the safe removal.
An organisation like Apple should absolutely be forced to delete the data, especially data collected using deceptive tactics
> An organisation like Apple should absolutely be forced to delete the data, especially data collected using deceptive tactics
As long as there are no consequences (regulation checks with fines) of not doing it correctly and/or if there is no observability and enforceability, it is just talk and does not matter in practice. Essentially, until the previous applies, it is just exchanging trust with words.
OpenBSD has never sent my passwords to Theo’s basement. I trust them without regulations. But more importantly, there’s a crew of capable hackers dissecting the code.
1. You can't demand something that cannot be enforced/monitored
2. You can't enforce/ push monitoring if there is no regulation in place, and systems are not transparent.
3. Enforcement/monitoring does not matter if there is no stick (fines) present
In the case of OpenBSD, you are using open system that you can verify your self. That alone makes them less likely to do something malicious (since they might get caught more likely!) and changes the trust. There is no financial carrot to make Apple products visible, as most of the users don't understand a thing about the technology and marketing might be more efficient than opening technology, which might result in intellectual property theft and lose of market position.
Since everything cannot be transparent in a competitive and commercial world, I think it would be okay to put at least 10 times bigger fines for those who do not have transparent systems and get caught on not following the regulations to get some balance.
We desperately need a free hard- & software (*nix) mobile platform, that is not exclusively owned by a for profit mega corporation and somewhat mainstream amongst the hacker community. Even better would be competing systems. I imagine these systems to have a high degree of modularity, incl. battery, and memory upgrades.
This is not an easy undertaking.
I don’t think regulating the megacorps is the answer. In a commercial world, they have the deeper pockets
Has been this way for at least a decade.
This also deletes the local copy of the passwords.
Or use the Export All Passwords feature in the Passwords app.
No, there is not. If there was a separate iCloud Keychain, then my passwords never would have gotten uploaded in the first place. Most of these passwords were Safari web form logins. Safari stores them where it wants.
> Or use the Export All Passwords feature in the Passwords app.
Export them to where? I want to use the operating system to store my passwords locally. I just don't want them in iCloud.
Settings -> Apple ID -> iCloud -> iCloud Passwords & Keychain -> Sync this Mac
iCloud only stores passwords when you're logged into iCloud. Logout and you're local only.
Would it be nice to have no configuration and customization? Sure. People have felt that way for as long as I can remember.
I've been using the Keychain app on the Mac for 20 years.
> you can clearly see the existence of multiple keychains and one explicitly labeled iCloud
There's no "iCloud" keychain if you don't use iCloud Keychain. There is a "Local Items" keychain. Let me emphasize LOCAL in the name. Unfortunately, what happens when iCloud Keychain is enabled (silently, without consent in my case), "Local Items" becomes "iCloud". macOS stores a lot of things in the Local Items keychain, including Safari web form passwords, which is why mine got silently uploaded to iCloud.
And you should also know...
Best practices for password storage use one-way hash functions (like bcrypt, Argon2, or PBKDF2).
I'm a happy Apple user, love the OS...just saying.
This is not true.
That is true if you are running a service that USES passwords. In that case you just need to confirm they match. That is not true if you are running a password manager where the user needs to be able to get their plain text password back out of the system.
https://support.apple.com/en-au/guide/security/secb0694df1a/...
It’s then stored in iCloud as a SQLite file and encrypted as it does for your other synced data.
For example, although I laboriously went through a ton of settings to make it less privacy-invading, I knew, for example, that I was still only one fumbled touch to a piece of glass away from Apple saying, "Oh, hey! I just grabbed all of your photos! Forever!" (Then Apple would say "Thanks!" in a sunny Californian way that normally is not every meaningful, but accidentally takes on meaning in the era of surveillance capitalism and AI training data.)
For tablet, I was using a PocketBook ereader (which works fine airgapped, and is friendly towards DRM-free ebooks, and doesn't need jailbreaking).
For most purposes, Debian Stable on my laptop, and on my GPU server.
They've been mostly reduced to single-use tokens thanks to password change policies.
And they're no better than email verification codes, which can be used to change the password anyway.
https://developer.apple.com/documentation/security/disabling...
The fact that the phone manufacturer has a more privileged access than the owner of the phone is absolute insanity.
It's not even about lies. It's about bugs and vulnerabilities, which every vendor has.
It's a perfectly fine decision, but Linux was, and still is, an option for plenty of people who develop for Apple hardware/software without daily driving it, myself included.
Well, I believe in dogfooding. I don't think it would be good for my software or my customers if I didn't use the same operating system as them. Besides, work-related activities are mostly what I use a computer for, so I'm not sure what I would even do with Linux.
Again, full respect for your decisions, but there are consequences to them and as your blog and experience shows, they are numerous and have serious impacts.
You: You'd be more in control over having your passwords silently uploaded to a third party without your knowledge or consent
If I mostly use a computer for work purposes, what do you think my passwords are for?
Also, I've been using a Mac since 2002, and iCloud Keychain got toggled on in 2024. It's kind of absurd to suggest, in 20/20 hindsight, that I should have expected it.
Do your thing buddy, but I'm not the one who had their (work) passwords were silently uploaded to iCloud without permission.
How many times do I have to explain that I use a computer mostly to do work, which is development of Apple software, requiring a Mac, and therefore most of my computer usage is necessarily on a Mac. Consequently, switching to a Linux machine as a "daily driver" is pointless, because I have nothing much to "drive" daily except my work.
Authentication: "Prove you are you" (hash functions)
Secure Storage: "Keep this secret but let me get it back later" (encryption)
Identification: "Track who/what this is" (UUIDs/tokens)
Password managers—all password managers—require stored passwords to be encrypted such that they can be decrypted. Otherwise they would have no possibly way to retrieve the stored secret for the sake of submitting it to the verifying party.
Best practice for verifiers is to use a one-way memory-hard password hash.
Keychain is a password manager.
This is what keychain does. You retrieve the passwords later.
So, no. It is not a one-way hash function as you stated.
Use Argon2 to hash a password before storing it in the password manager. Now the user visits that website and wants to log in. What is it that the password manager pastes into the login form?
Answer: the plaintext password. But how do you get that out of the hashed value you stored earlier? You don’t. Ergo, password managers cannot use hashing functions to store their contents.
Next time you insult someone, better use your cognition powers to avoid looking like that which you call others
By GP, u/blitzar's comment, my cognition tells me that his comment meant anyone can break AES 256-bit encryption, including Apple, but in this context, he could have meant everyone else
One for password key column, one for value column and one for the password file.
Still no proof that there’s no back door, but as far as the system on the surface goes, it does make sense.
And guess who has the decryption keys…?
And the decryption keys are stored on your devices in the Secure Enclave. Apple doesn’t have the keys on their servers.
The fact that Apple's software can access the keys stored on the device to decrypt the password after you securely authenticate is neither here nor there.
>Passwords and Keychain (6): End-to-end
Here’s a big one: https://arstechnica.com/gadgets/2007/11/be-cautious-of-that-...
The article contains few details. More insight is at the discussion on https://www.cableforum.uk/board/showthread.php?p=34430700
Briefly, when implementing file moving in (closed source) Finder code, someone at Apple who was apparently a beginner programmer or student intern made an elementary error that reliably destroyed files. The system already had a battle-tested mv command in its BSD subsystem, but they didn’t use that code. The point of this story (and, yes, there is a large handful of similar stories) is what it tells you about Apple’s culture and practices around testing, care, and concern for real soundness and quality (as opposed to appearance).
Apple does take this stuff seriously. Implying otherwise is just absurd.
What policy are you saying we should use to evaluate software? In particular, what’s left if we’re saying it’s no longer good enough to have learned from mistakes? I supported a lab full of computational scientists who heavily used their Macs with external storage at that time and this caused no problems for anyone, so I also am looking for something more quantitative like whether a bug which only affected handful of users disqualifies usage for everyone.
Former Apple tech, G3/G4 iBook/PowerBook days. Crates of logic boards shipped in - most static-killed due to sand inside the crates. These were supposed to be used for repairing units that failed fresh from the manufacturing line.
NVRAM consistently killed itself.
Let me get out of my date of professional work in Apple repair - Trashcan Mac Pro - That one was very incompetently-designed given how badly people wanted to upgrade it and just could not due to space and thermal constraints.
One of my friends about 4 years ago bought an iMac, 24" model. FIVE RMAs due to hard drive failing. They kept replacing it with the same drive brand and type, and likely from the same manufacturing batch, because that's an INSANELY high RMA rate for a single unit for the same piece of hardware.
And that's just MY horror stories, and only from the HARDWARE perspective.
And Cashmere, Apple's diag software, was a total piece of crap that couldn't tell you half of what was truly wrong with the system. So there's a bit of software horror for ya. Most Apple techs were shooting blind unless it was a specific problem. And the poor OS imaging techs - it's fun having school system laptops that are LOCKED to a specific OSX version and can NOT be upgraded. Not for security, NOTHING. You have to install that specific image for that specific school district, and ship it out. The machines can not be upgraded on the OS side. What a security nightmare that must have been.
Shall I keep going? I'm sure if I thought hard enough I could find more incompetence which I hated while working as an Apple repair tech.
Maybe someone can reverse engineer, attach a debugger and confirm, or analyze the traffic with a Transparent MITM Proxy on the new machine. Just grep for your password in the traffic captured, should be easy.
And then write a blog post about that. Let's see what happens.
For the May 2024 version the section on iCloud Keychain is on page 158.
Is it like that in reality? Should be easy to confirm with a MITM Transparent Proxy, someone should try to find out. Just out of curiosity.
It's exciting to find a company like Apple making a mistake, and they do make mistakes, but boy do they have quality software and it's getting better by the day. Just have a look at their SDK and interfaces: uniform and practical.