Skip to content
Thoughtful, detailed coverage of everything Apple for 29 years
and the TidBITS Content Network for Apple professionals
17 comments

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.

Shows a login screen on an iPhone that prompts for a Mac password to unlock iCloud data
I had to take a photo of this unusual login screen, as it was during setup and screen capture wasn’t available.

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, but they include iCloud Keychain, Screen Time information, Health data, Wi-Fi passwords, the People album in Photos, and the new Find Me 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:

  1. 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.)
  2. 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.
  3. 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.
  4. 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.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For 29 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

Comments About Why Apple Asks for Your Passcode or Password with a New Login (and Why It’s Safe)

Notable Replies

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

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

    • Contact data is revealed to Apple when iCloud is used for synching.
    • There is no good business reason to not teach every support person that.
      And to insist that they tell customers the facts on every call.
    • There is no technical reason to not encrypt end-to-end.
    • There is no excuse for not providing on-line documentation of the facts.
  3. 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.

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

  5. And Apple does have the keys, so they have the ability to decrypt if required.

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

  7. 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. :clap::slight_smile::+1::heart_eyes:

    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?

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

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

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

  11. Really great to know. Many thanks, Glenn! :slight_smile:

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

  13. I’m not sure how @joe is handling that, so I’ve tagged him in. Do you get other updates?

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

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

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

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

Join the discussion in the TidBITS Discourse forum

Participants