Why Apple Asks for Your Passcode or Password with a New Login (and Why It’s Safe)
If you’ve set up or restored an Apple device recently and have two-factor authentication enabled on your Apple ID, you may have seen a message during configuration that defies your understanding of how Apple maintains device privacy and account security.
The message reads something like, “Enter Mac Password. Enter the password you use to unlock the Mac ‘name here’. This password protects your Apple ID, saved passwords, and other data stored in iCloud. Your password is encrypted and cannot be read by Apple.” The prompt might instead ask for your iPhone or iPad passcode.
Doesn’t this seem contradictory, confusing, and just plain wrong? Why would Apple ask for the password or passcode for one of your other devices? Could it be some sort of scam? What exactly is going on here?
I encountered this issue, as did Take Control publisher Joe Kissell, in preparing the iOS 13 and iPadOS 13 revision to my long-running networking and security book, Connect and Secure Your iPhone and iPad. (It has a new, shorter title in this release, and is already updated for iOS 13.1—check it out if you’re looking for more information about iOS networking, privacy, and security.)
While I had heard of this prompt happening once last year, I had never seen it myself. Now I’ve figured out what is going on by reviewing Apple’s documentation and deducing the missing pieces. The short answer is that this prompt is actually Apple working to protect your security, and the explanation is accurate. But it’s not sufficiently detailed—that would require screens of text—to explain what’s going on. Here’s the skinny.
iCloud Stores Two Kinds of Secured Data for You
All the data that’s synced between your devices via iCloud is encrypted while in transit (generally using HTTPS) and at rest on Apple’s servers. Some of it is available in decrypted form if you were to access it via iCloud.com. For that subset, Apple maintains the encryption keys that protect the data when it’s at rest, and it could turn over that data if forced to by law enforcement.
Apple discloses which data is stored with encryption keys it possesses. In very rare circumstances, someone who compromised Apple’s keys or server security could extract that iCloud.com-accessible information from a transmission or from iCloud. It’s extremely unlikely, but it’s not strictly impossible.
This data could also be at risk in a successful phishing attack. Phishing requires only that an attacker fools someone into thinking they are entering their credentials into a legitimate site that is, instead, a man-in-the-middle. There are many kinds of phishing attacks, one severe type of which involves obtaining fraudulently issued HTTPS certificates that can have all the trappings of a legitimate and secure site.
The attacker could then simply use your login name and password to initiate an attempt to log in to iCloud, even triggering Apple to send you an extra login token used for two-factor authentication, which, if you entered it on the phishing site, could be used by the attacker at iCloud.
Apple users have been phished, of course, although as far as I know, Apple has never suffered from a fraudulent certificate attack. Some visitors to Google sites were phished in this way on multiple occasions several years ago. Since then, certificate-issuing and -tracking procedures and the way browsers check for legitimately issued documents have substantially reduced but not eliminated that particular risk.
Because of phishing risks, Apple has chosen to protect some data that it views as highly secure or very private with end-to-end encryption that prevents Apple from knowing anything about the contents of the synced data. Apple doesn’t possess any of the keys required to decrypt this data passing through its servers. Instead, those keys reside only on individual iPhones, iPads, and Macs.
There’s a full list of end-to-end encrypted services at Apple’s iCloud security overview page; they include iCloud Keychain, Screen Time information, Health data, Wi-Fi passwords, the People album in Photos, and the new Find My service’s crowdsourced location information. There are also likely other bits of data that facilitate device-to-device interactions.
As a result, you cannot view these categories of data at iCloud.com, only using your devices. In essence, iCloud acts as a sync service with zero knowledge about what it’s transmitting. If Apple were asked to disclose this information by a government, it could only produce unreadable encrypted data, by design. (This approach is distinct from the way Apple stores even more sensitive data—credit-card numbers, passcodes, and fingerprint or face parameters—in the Secure Enclave of iPhones, iPads, and Macs with T2 chips. That data never even leaves the Secure Enclave, and much of it is stored in the chip already irreversibly transformed through one-way encryption.)
Apple’s iCloud syncing system relies on public-key cryptography, which uses linked pairs of keys: one public and one private. The public key can be shared freely and used by anyone who wants to encrypt material meant for the owner of the private key, who can then decrypt that data. For iCloud Keychain and similar sensitive data, Apple has your devices generate and maintain a set of public and private keys that enable interaction with the information synced across iCloud. The devices never reveal their private keys and have the public keys of all the other devices connected to an iCloud account.
The data protected in this way is stored as individual packages—for example, a URL, account name, and password as a single unit—and identified with random metadata that’s meaningless except to establish a unique ID for each data package. Devices in the user’s sync set, including newly enrolled hardware, sync by exchanging metadata information. Let’s say your iPhone is missing a Web site login you just created on your Mac. The Mac encrypts the login entry with the public key of the iPhone, which receives it via iCloud sync, and then decrypts it with its private key. This approach is both typical and sensible.
The hard part isn’t syncing data privately. Rather, it comes when you want to add a new device to this set. To understand how that works, we need to understand the role of your iCloud password.
An Extra Element to Protect against Interception
Apple’s iOS 12 security white paper explains this system in some depth, noting that your iCloud Apple ID account password by itself can be used to enroll a new device. That isn’t as worrying as it might sound, because Apple doesn’t know your password. Instead, it stores only an encrypted form of the password. Whenever you enter your password, it’s run through a one-way encryption algorithm that performs a vast number of mathematical operations—the process is called “hashing”—that makes it effectively impossible to determine the original password. (This is also used for a lot of data stored in a Secure Enclave, like your passcode.)
You could enable an iCloud Security Code as an “out-of-band” element—something that is never transmitted by the same means as other data. Out-of-band elements are a common way to block data hijacking by requiring a secret that has never been put online. In this case, it’s something you create or Apple creates for you on one device and that you enter on another.
(Never heard of an iCloud Security Code? You’re not alone! It’s barely mentioned on Apple’s site, and Apple’s white paper doesn’t discuss the code deeply. I recall using one years ago, and TidBITS publisher Adam Engst had never heard the term before editing this article.)
But there’s a flaw in both the iCloud password and the iCloud Security Code approaches, and I wonder if that’s why Apple is now asking for passwords or passcodes from other devices in your sync set. The iCloud Security Code is yet another piece of information to remember and deal with and thus runs counter to Apple’s commitment to simplicity. It was also created when iCloud Keychain was the only set of data Apple secured end-to-end and synced via iCloud, and before both two-step verification and the later two-factor authentication for Apple ID. It may not be robust enough to match Apple’s current security and authentication requirements.
As for the iCloud password, it suffers from a different set of concerns. While Apple doesn’t know your iCloud password, whenever you log in at iCloud.com, your encrypted password is sent to Apple, which holds it just long enough to perform the hash and test it against its stored value. However, it’s not inconceivable—though, again, it’s unlikely—that the password could be captured during that transmission, phished, or stolen in some other way. Apple obviously thinks about it in this way: Since it’s conceivable that the password could be intercepted, Apple has to defend against interception as though it happens every day.
Some companies have tried to move away from the need to transfer even a hashed password. AgileBits, for instance, built 1Password.com around newer browser-based encryption algorithms—no unencrypted passwords or data are stored by AgileBits or ever sent to the browser. Instead, the browser itself performs all the necessary encryption and sends the encrypted data to AgileBits. After login, the 1Password.com servers only send encrypted packages to the user’s browser, which holds encryption keys locally and only for the duration of the session.
Apple hasn’t transitioned to this method with iCloud.com, and so it makes sense that instead of relying on an iCloud password, which could be stolen or phished, it has instead moved to this device-passcode/password system. Apple hasn’t yet documented this new approach, which is why I’m not being more precise about how it all works. None of the text on the screen users see appears on Apple’s support or marketing sites, and there’s no mention of the process in the white paper noted above or elsewhere. But I’ve heard about the process previously from readers, Take Control publisher Joe Kissell recently saw it on setting up a new device, and I finally saw it after upgrading to iOS 13 on my iPhone.
Here’s how the new system works, as far as I can determine:
- You log into your Apple ID on the device you’re setting up and confirm a second-factor login. (Password-only Apple ID accounts, which Apple strongly discourages and which we recommend against, don’t seem to get these dialogs.)
- On at least one of the devices in the iCloud sync set, Apple adds an encrypted version of that device’s passcode or password to the set of shared information. The only information attached to that payload that Apple can read is the type of device and the name of the device.
- Apple syncs this information to iCloud, and the setup process on the new device then pulls it down, prompting you to enter the passcode or password.
- Once you enter the correct passcode or password, the new device dumps the passcode/password data from the set, instead generating and relying on a new pair of encryption keys, just like the other devices. The new device becomes part of the trusted set of devices that can sync your end-to-end encrypted iCloud data.
It’s possible that Apple retains the encrypted passcode and password of the shared key for every device that’s in the set. However, that would seem to be an ongoing risk, as it would conceivably allow someone who obtains that secret to gain further access.
What this process appears to show is that Apple never sees, handles, or stores your device passcode or password in unencrypted form, and it never passes the passcode or password over anything but secure transport. It requires only your Apple ID account name and password, sent over HTTPS, as the first stage of logging into iCloud, but not for the later stages.
Overall, this new approach seems rational and secure. Apple would do well to give users more confidence in what’s happening by providing an explanatory support document, and I hope Apple will give in-depth details when it updates the iOS security white paper for iOS 13.
When I got a new phone recently it was asking me for a password and I put in my iCloud password and then realized it was for a MacAir that I keep around and use 2-3 times a year. I thought that was unusual, but knew the (not very secure) password I use with it. Glad this explains why
There has been a longstanding bug in using iTunes to synch between phone and mac. (Apple Support says it is a known bug and that it might be fixed in some future release.) I mention that only to let you know why I have spoken with Apple Support about synching Contacts, three different times over the last some months.
I had never used iCloud, because I keep data in Contacts that I am required by Federal law to not disclose. So I can’t give that data to Apple. Because iCloud is Apple’s recommended option, I have closely questioned the support person about encryption of my data on each of these three calls. Each time I have been told–in no uncertain terms–that Contact data is always encrypted when using iCloud.
Correct me if I am wrong, folks:
And to insist that they tell customers the facts on every call.
I’m not quite sure what you’re looking for, but as I understand things, for Apple to display your contacts at iCloud.com, it must have the encryption key necessary to decrypt the data. So the contact data is encrypted in transit and at rest, but Apple could be legally forced to disclose it.
If you follow the link in the article to the page in which Apple explains how it secures different data, it makes it completely clear that contact data is only encrypted in transit by Apple and at rest by Apple using keys Apple has.
I agree! When they built the system, there was. Now, modern browsers all in-browser encryption as I discuss in the article. So if I were Queen or King of Apple, I would be revamping calendars and contacts at the very least to use end-to-end encryption and require using device-based approval to pass decryption information to a browser (the iCloud password shouldn’t be used as I note in the article).
Given Apple can enable Safari to manage Apple Pay from a browser, I am positive they could end-to-end encrypt contact info.
Third-party apps already consult a central repository of information for calendars and contacts, so they would just need perhaps extra permissions in iOS/iPadOS/macOS to make that work with end-to-end encryption.
And Apple does have the keys, so they have the ability to decrypt if required.
I have seen this prompt at least twice, and trial and error convinced me that the message should read something like, “Enter an Admin password that would unlock the Mac…". As I understand the article, that shouldn’t be the case, but I believe entering my user password was never successful.
Very nice article, Glenn. I love it when TidBITS ends up explaining something that not even a serious search on Apple.com or any KB articles would spell out. Big round of applause.
I have one question since you mention iCloud Keychain. I have in the past never used it and I admit it’s because I was being deliberately paranoid. To me it just felt a bit too much like putting all eggs in one basket. I figured, if I use that and Apple or I somehow get hacked, that person will not just have access to the hacked device/account or to some passwords, but with iCloud Keychain, that hacker would effectively have ALL my passwords. I use primarily two devices (MBP and Phone) and there’s only a handful of passwords I use on both devices so in the past I felt having to update these passwords twice was a small price to pay for not having all those eggs in that one iCloud basket. But now reading your most interesting article I get the impression that this might have been not just paranoid, but actually misguided because, as I understand, Apple actually never has access to those user/pass combos stored in iCloud Keychain thanks to E2E encryption — only my devices can display those user/pass combos. In essence, even Apple getting seriously hacked (not something I’m actually worried about, but again, for the sake of argument being a tad paranoid) would not be enough to expose my user/pass data. For that to happen, I myself would have to get hacked. Is that correct? In that case I suppose you could reasonably argue, that if I’m being careful enough not to fall victim to social engineering etc. I’d be safer using iCloud Keychain after all since it enables me to use super long and hard passwords that are frequently changed. Am I missing something here in your opinion?
That’s correct. I would never store my passwords in a system in which obtaining a password and plugging it into a Web site would give someone access to my data. Long ago, LastPass had such a password-based central model, while 1Password avoided Web-based access for the same reason. LastPass swapped out to browser-based encryption and no transmission of your password and 1Password added its Web option for the same reason.
iCloud Keychain was engineered from the start with a similar philosophy, which is why I’ve always used it. It has a design philosophy that really requires end-point device and credential acquisition. Even if someone has your iCloud password, they can’t obtain iCloud Keychain entries without the passcode of another device. Even if someone obtains your second factor in a 2FA account, iCloud.com doesn’t make this information available even in encrypted form. You have to be on an Apple device, logged in iCloud, validated with two factor if enabled, and then enter the passcode of another device in your set to even get the data synced!
A compromise of Apple’s systems would require still code changes at iCloud and into iOS, iPadOS, or macOS that would allow password acquisition in order to view your decrypted passwords. Seems very unlikely!
Thanks, Glenn. That really helps clarify.
In your experience, are there any pitfalls to turning on iCloud Keychain on your Macs and iDevices when those devices have in the past already been used to save a lot of user/pass data? Anything special to look out for? Or just turn it on and forget?
Great question—because it’s managed through Keychain in iOS/iPadOS and macOS on each device, iCloud Keychain seems to handle merging data sets fine. I can’t think of a problem I’ve had with it.
Really great to know. Many thanks, Glenn!
I was never notified of the 1.0.3 update to your book, Glenn so I went to my TCO library and downloaded it from there.
I’m not sure how @joe is handling that, so I’ve tagged him in. Do you get other updates?
Thanks for this detailed analysis. I have seen what I imagine is a related behaviour - I have not been able to nail down the circumstances.
But it seems to be that (sometimes) I try to log in to iCloud.com on a desktop browser, and a screen appears wanting a code that it says it has sent to another device. But the code then appears as a popup on that same machine. I enter the code, and all is good. But I don’t feel like this is adding any security! Any ideas?
I have actually written entire articles about this! It’s a little weird, but Apple’s version of a second factor is not fully accepted by security experts as being a true second factor. It’s sometimes a 1.75-factor or some approximate.
When you log in to your Apple ID with two-factor authentication from a computer that is logged in to your iCloud Apple ID, that computer is a trusted device. When you use the browser, the browser (even Safari) has no way to check whether it is running on a trusted advice. It’s probably a bad idea for it even to try.
So when Apple sends you a code on the same device, it’s really a confirmation that you have a trusted device (your computer) in your possession to validate the log in. It feels weird, but it’s two separate modalities: a browser and the trusted device.
Yes, Glenn, I get update notifications of my purchased TCO books; of course I can also click a link in a TCO book to see if there are any updates. I looked for something similar in the 1.0 edition of your book but I didn’t see it.
I don’t get asked for passwords of my other hardware, but I do get asked REPEATEDLY to enter my Apple IDs passwords in Settings in my iDevices even though I have done so ad nauseum.
Hi Glenn,
Very good article. Only one thing that I think I don’t understand.
For example,
So, my question is if I go to add the third device C, so which passcode/password I need to enter? Or it’s randomly and I can’t know this?
Thank you.
Apple controls this, so there’s no way to tell. When you set up device C, Apple might ask you to enter the passcode from either device A or B. This may be another attempt to reduce risk or it might be just random.
If I understand the question, the answer is worse than @glennf said. Recently I needed to re-authenticate for iCloud access on a Macintosh, and part of the process asked for something like the password you use to access this computer. It turned out that it wanted the Admin password for that computer, not the password of the user account that needed to re-authenticate. Similarly, an iOS device asked for the password for a Macintosh computer, but didn’t specify which account. Apple surely could have designed a better interface.
Yes, I think this security feature is poorly explained, undocumented, and confusing, despite having a worthwhile purpose that shouldn’t be bypassed. As I note, if you try to search for the message you see on your Apple product at an Apple site, there’s no information. It has the feeling of phishing or malware.
Do you have an idea if the rather old assessment from
Andrey Belenko (https://speakerdeck.com/belenko/on-the-security-of-the-icloud-keychain) is still valid?
Hello, apologies for responding to an older thread but this is only one of about three hits I get when researching this issue. Which has me surprised there isn’t more uproar. I first encountered it today and I am a bit outraged.
Despite the “security” I just find it atrocious that my Phone wants my Computer password. I guess I’m fairly privacy minded and consider my local password to be very sensitive. It’s what controls access to my local machine and hard drive after all. That Apple is somehow using it for this purpose without my knowledge has me very upset.
Apple at least needs to make it clear that it is being used for this purpose. They are usually so good about using the Privacy Icon and “how your data is managed” links during the setup screens. It is not clear at all that your computer password is also going to be used to verify iCloud stuff.
There needs to be an opt-out. I’d much rather use a random passphrase to verify iCloud than my sensitive computer password. Or even like a random credit card number or something.
Despite the “security”, this seems more like a “backdoor” to me. For instance, I had used a much less secure login password on my wife’s computer… and now I see that it is a valid one for authenticating iCloud. If I have different logins on 3-4 computers, now any of them can be used to verify my iCloud? No thanks. Of course now that I know I can choose better passwords… but the problem still remains that I don’t want my computer password to be used in this way.
(Isn’t there an option to use your iCloud password as your computer password anyway? I specifically don’t do that because I don’t want my computer password “in the cloud”, even encrypted.)
Anyway, I’m pretty surprised there isn’t more chatter about this on the web. Seem like a very bad use of computer passwords and it’s downright freaky that my Phone wants to know my Computer password or vice versa.
Thanks for letting me vent. I called and sent feedback to Apple but I’m not confident it will even be read, much less acted on.
Oh, one other thing I picked up at another link. This also seems to be related to the T1/T2 chip. My Phone only gave me the option to enter the password on my new Mac Studio, and MacBook Pro. My older iMac wasn’t an option. So I think this is why I am just seeing this now. I have been using a 2014 iMac until fairly recently.
I confess that I was absolutely baffled about it the first time I saw it. It took a while to work through whether it was a good or bad idea.
This is the crux: it’s terribly explained and hasn’t gotten better.
There’s no good way to do that because of how Apple secures each device. So the “opt-out” is “don’t use iCloud Keychain.” Otherwise, Apple would be providing a way for a malicious party to potentially generate or obtain encryption information that could be used to join a sync set.
Not precisely—but this goes back to Apple’s bad explanation. The password doesn’t leave your device. Let’s say you’re on an iPhone and it prompts you to enter your iMac’s password. Apple uses the password hash on the iMac to secure the iCloud Keychain keys. Apple doesn’t know your iMac password. The password isn’t sent to your iPhone—it’s only used to encrypt the iCloud Keychain pairing information. On your iPhone, you enter the iMac password. That password is used to generate the hash to unlock the iCloud Keychain pairing keys. The password never leaves your iPhone and the hash is destroyed.
Presumably, it should be possible to use the password from any device in the sync-set, since each one’s password (or biometrics) are valid for generating these hashes.
Is that iMac using an iCloud Keychain? If it isn’t then it’s not in the sync-set.
If it is, then I have no explanation.
Thanks very much for the replies!
I admit to not fully understanding the technology, but it seems like an “iCloud Security Code” or just anything else could work. Apple is generating a hash or something with my computer password. I don’t see why it can’t it use some other piece of info I enter on my device instead. I’d be happier with almost anything else than my computer password. Even my birthday or something. I feel confident enough with the 2FA by itself, and I guess I do appreciate the extra security for the end-to-end encrypted stuff. But just hate that it uses my computer login.
The Apple Representative did say I could turn off 2FA but of course that’s not a good alternative!
You can set an “iCloud Recovery Password” which I might try. But I’m pretty sure that’s just for if you forget your iCloud password and not for this purpose.
Apple could keep the simplicity if it defaulted to your device passcodes but allowed an alternative passphrase. But perhaps that’s just not possible as you say. /sigh
The old iMac was not using iCloud Keychain, but it did have “Home” as in Homekit turned on which is part of the end-to-end encrypted data according to here but maybe only Keychain counts:
https://support.apple.com/en-us/HT202303
I don’t think I have any of the other end-to-end things on, but often when setting up a new machine you have to turn stuff off manually, so maybe some of those things defaulted to on? Like I have never intentionally used iCloud Keychain but I think I have found it on from time to time when setting up new devices.
Regardless of what triggers it. It seems I have to live with Apple using my passwords in this way. I’m trying to decide if I should be paranoid enough to demote my computer user accounts using iCloud to non-admin status and set up a dedicated admin user. I suppose there are other security reasons to do that but I haven’t felt the need before…
Oh… if you refuse to enter any passwords, it gives you the option to reset end-to-end encrypted data. Presumably I’m not using any of it from iCloud anyway, so I could just reset it. But that doesn’t change the problem that I feel my computer passwords are now being used in a way I’m uncomfortable with.
Apple wants iCloud Keychain security tied deeply to device possession and a high level of permission. A code can be stolen; your password to another device, unlikely. They build this level of security based on what they see in hacking, so there is probably a really good reason they won’t disclose as to why they went to this level. You can simply opt to not use iCloud Keychain, is their philosophy; you could use 1Password, LastPass, etc., and rely on a different model for security.
Also, you can’t turn 2FA off—two weeks after it’s enabled on an Apple ID account, it can never be turned off. So that’s bad advice from an Apple rep.
Thanks again for your response. It does help me feel a little more comfortable with what’s going on.
I will say it seems to be more than just iCloud Keychain (which I have turned off) otherwise I would consider using a different PW manager. I think it must happen when you use anything that is end-to-end encrypted as listed in the apple support doc. Although I don’t even have much (or any) of that stuff turned on. (After signing into iCloud for the first time, Siri and Home always default to on which I have to turn off.) Not sure if you can turn off stuff like Maps and Wi-Fi passwords which is perhaps why it is triggering for me.
Can I clarify my understanding with a specific example? Let’s say I have a crazy random iCloud login password and several devices with crazy random passcodes as part of my account, but then I add a device with the passcode ‘1234’. Does this implementation mean that anyone (Apple, hacker, etc) who just gets Apple’s copy of my end-to-end encrypted data could decrypt it if they could guess the passcode ‘1234’?
My understanding is that the answer is no, because the ultimate end-to-end encryption key (private key) is also tied to the individual device itself, so that copy of the data would only be useful/unencryptable on the actual device with the weak passcode ‘1234’. Is this right?
i.e. Fundamentally, the security of the server copy of my end-to-end encrypted data is not tied to the strength of the device passcode, even though when I enter my device passcode in this prompt it sorta feels like it is?
Yes, the passcode is entangled with the device’s UID. It’s worth reading the full Platform Security Guide if you’re interested; it’s very well done.
No, because “1234” is only the key to unlock the device. The actual decryption key is stored in the device’s Secure Enclave.
One of the key features of the Secure Enclave is that you can write keys into it, but you can never read them back. You use the keys by passing the ciphertext to the crypto chip (T2 or built-in to the A- and M-series SoCs), and the chip sends back the plaintext (if the correct key has been installed).
So, someone using your “1234” passcode could not use it to decrypt intercepted content. Nor could they use it to extract the necessary keys from your phone (if they got access to it).
They could, however, use that passcode to access your phone (again, assuming they got access to it) and use it’s apps to read the data and transfer it elsewhere (e-mail, AirDrop, etc.). They could also use this compromised phone to provide the 2FA authentication needed to authorize a new device for the data (assuming they also had your iCloud password).
In other words, an easily-guessed passcode does reduce security, but only in conjunction with other factors, like the bad guys getting possession of your phone and/or your iCloud password.
Awesome thanks so much I understand much better now!