If your Mac is connected to the Internet but suddenly starts asking for your password, you should generally try again later, and if necessary work with your email provider to resolve. If you're using Apple's iCloud Mail, learn how to resolve issues with iCloud Mail.

1. How To Fix A Mac That Keeps Asking For Icloud Password
2. Outlook For Mac Keeps Asking For Icloud Password

My iPhone keeps asking for my iCloud password and says it - Answered by a verified Mac Support Specialist We use cookies to give you the best possible experience on our website. By continuing to use this site you consent to the use of cookies on your device as described in our cookie policy unless you have disabled them.

Why is Mail asking for your password?

Mail asks for your password when it is connecting to your email provider, but can't connect to your email account because your email provider isn't accepting your email password.

• If your iPhone keeps asking for iCloud password, again and again, you can try these methods to fix it. This is an old bug and the causes of iPhone keeps asking for iCloud password are complex. But don't worry, it can be solved easily. You should try below 7 ordinary solutions to fix this problem.
• SOLVED: Mac Keeps Asking for Keychain “Local Items” Password Keychain Access is a feature built into Mac’s that stores and saves all the passwords.

Your email provider may reject your password for several reasons, including:

• You're not using your current email password. If you updated the password on another device, make sure that you're using the same password on your Mac.
• Your email provider needs you to update or reset your password for security reasons. For example, if you're using Google’s two-step verification, your Gmail account in Mail requires the appropriate app-specific password.
• Your email provider deactivated or suspended your account. Contact your email provider for help.
  

Check your password in Internet Accounts preferences

Depending on the type of email account you're using, you might be able to correct the password as follows:

1. Quit Mail. If it doesn't quit, you can force it to quit.
2. Choose Apple menu  > System Preferences, then click Internet Accounts.
3. Select your mail account in the sidebar.
4. If you see a password field for your account, delete the password and type the correct password.
   
5. Close System Preferences, then open Mail and try using your account again.

If Mail still asks for your password, the password is probably incorrect. Your email provider can help you verify your email settings and make sure that you're using the correct password.

Test using webmail

Many email providers offer webmail, which is a way to use email with a web browser such as Safari, instead of with an email app such as Mail. For example, if you're using an iCloud Mail account, you can use iCloud.com to send and receive email.

Because the password that you use with Mail is usually the same password that you use with webmail, try signing in to webmail with that password. If it doesn't work there either, your password is probably incorrect. Your email provider can help you verify your email settings and make sure that you're using the correct password for the Mail app.

Remove your account, then add it back

If no other solutions work, try setting up your email account again. To do that, first remove your email account, then add the account back.

Learn more

• If you're using Apple's iCloud Mail, learn how to resolve issues with iCloud Mail. The password that you use with iCloud Mail is your Apple ID password. Learn what to do if you forgot your Apple ID password or want to change your Apple ID password.
• If you forgot or want to change the email password for a different email service, contact the email provider or request a password reset from their website.

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.

How To Fix A Mac That Keeps Asking For Icloud Password

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

Outlook For Mac Keeps Asking For Icloud Password

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.