Hacker News Reader

Comment by Veen | Hacker News Reader

This may be annoying, but it’s uploading encrypted versions of passwords, not passwords themselves. Keychain is end-to-end encrypted so no one else can read them.

View on HN

End-to-end encrypted but Apple issues the keys when you log in and I don't think they offer any way to require explicit verification of new devices.

When importing the passwords into a new devices you’re required to enter the device password of whatever device created the password initially.

Still no proof that there’s no back door, but as far as the system on the surface goes, it does make sense.

Oh, I didn't notice that. I guess this is using their hosted HSMs to do the PIN check? Otherwise it would be trivial to brute force. But if they are using hosted then I think it can be considered a proper E2EE system.

Are you sure Apple can’t read them too?

They say they can’t, but it’s impossible to be certain. Although, if you distrust Apple enough to think they might lie about it, you probably wouldn’t want to use any Apple device or services. They already have privileged access to the software and hardware.

> Although, if you distrust Apple enough to think they might lie about it, you probably wouldn’t want to use any Apple device or services.

It's not even about lies. It's about bugs and vulnerabilities, which every vendor has.

I'm considered switching to Mac from linux and I came across your blog which has been very informative. What made you chose mac over linux?

I didn't choose Mac over Linux. I chose Mac over Windows in the year 2002, and I became a Mac developer in 2006. Things were a lot different back then. Now it's too late for me, because my entire livelihood depends on Mac.

Not throwing shade here on your decision, but that's still choosing Mac over Linux and every day you continue to make that choice.

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.

> 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.

You'd be more in control over having your passwords silently uploaded to a third party without your knowledge or consent, for starters.

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.

Me: work-related activities are mostly what I use a computer for, so I'm not sure what I would even do with Linux.

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.

Not sure where or what "work passwords" has to do with it, passwords are passwords especially if you're running your own business, which it seems you are.

Do your thing buddy, but I'm not the one who had their (work) passwords were silently uploaded to iCloud without permission.

> Not sure where or what "work passwords" has to do with it

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.

Fair enough, I guess you are overall happy with the OS though

Yes. SIP means Apple is the real sudo now. You can’t disable their special relationship on their computers

Yes you can. Here are the instructions to disable it:

https://developer.apple.com/documentation/security/disabling...

Doesn't disabling SIP weaken the security?

> They already have privileged access to the software and hardware.

The fact that the phone manufacturer has a more privileged access than the owner of the phone is absolute insanity.

That's pretty normal, isn't it? Do you have more privileged access to your phone than its kernel does?

I'd prefer it to work like a normal computer where there's a separation of the OS and the hardware. But sure, other phones aren't better.

I'm not sure I've used any operating system where I have more privilege than the kernel does.

You can escalate your privilege if you can freely choose which kernel to run. Maybe you won’t have _more_ privilege than the kernel but you would certainly have as much.

I can escalate my privilege to be higher than the kernel's?

Are you sure AES 256-bit hasn't been broken?

They own the OS. They don't need to break it to access your passwords

I am not sure if you are ignorant or what, but GP obviously means someone else other than Apple

It means Apple. See: "Are you sure Apple can’t read them too?".

Next time you insult someone, better use your cognition powers to avoid looking like that which you call others

My bad, I didn't mean to insult you. I meant it as a criticism

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

Note that you have to break 3 independent levels of AES encryption.

One for password key column, one for value column and one for the password file.

Best practices for password storage use one-way hash functions (like bcrypt, Argon2, or PBKDF2) rather than encryption algorithms like AES. AES is not one way and in theory you can generate 2nd, 3rd, etc. master keys to decrypt. :)

That’s relevant when storing a users password to verify that they’ve entered the correct data, but password managers (which Keychain effectively is, I believe) need to be able to retrieve the original password

Frankly, you're confusing hashing algorithms, encryption and "IDs".

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)

You are deeply confused as to how password managers work.

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.

>Secure Storage: "Keep this secret but let me get it back later" (encryption)

This is what keychain does. You retrieve the passwords later.

So, no. It is not a one-way hash function as you stated.

A thought experiment:

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.

How do you know?

https://support.apple.com/en-us/102651

>Passwords and Keychain (6): End-to-end

I understand that Apple claims that this is the case. But given their history of incompetence in the past, that claim affords me little confidence that their closed source software does not contain critical bugs that might lead to recording or exposing the users’ plaintext passwords.

“History of incompetence” really needs some citations, especially for the belief that open source tools are better - they had Gotofail but OpenSSL had Heartbleed, etc. One of the better questions to ask is not how the source code is managed but how it’s audited: there’s a long history of problems in both open and closed software but well audited codebases tend to have them patched before exploits are publicly available.

"“History of incompetence” really needs some citations"

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.

> “History of incompetence” really needs some citations

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).

So you’re saying that having a data loss condition 17 years ago which only affected a subset of users who lost their storage connection in the middle of a move operation tells us something about their products today? Does that also mean that I shouldn’t use Linux because ReiserFS lost data on local storage in some cases back then, or btrfs did so more recently?

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.

Something from almost 20 years ago doesn’t quite work the way you think it does.

Apple does take this stuff seriously. Implying otherwise is just absurd.

Why do you want to know?

Indeed, why would you want to know if the keys to your correspondence, bank accounts, investment logins, crypto fortune, backup OTP codes or whatever you might be using a password for, are sent in the clear to a third party.

If they are uploading the PW and not the hash then… they are uploading the passwords themselves, encrypted or not.

And guess who has the decryption keys…?

Of course. Apple has to decrypt the passwords when it pre-fills the browser.

And the decryption keys are stored on your devices in the Secure Enclave. Apple doesn’t have the keys on their servers.

Either way the passwords are being uploaded, which is the comment I was replying to.

The ciphertext is not the plaintext (obviously). So an encrypted password is not a password. An encrypted password is a string resulting from the application of an encryption algorithm and a key to a password. Uploading that string is not uploading the password.

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.

Your response implied something that is outright incorrect, which is what is at issue here.

Reply on news.ycombinator.com