There is a lot of documentation from Apple on how all of this works, but this is indeed expected behaviour. A way to make this smoother would have been:
1. Doing the password reset
2. Reboot straight back into recovery
3. Update your new password back into your old password
4. Boot into macOS, your default keychain will unlock but you'll still have to re-authenticate to iCloud since your machine-user identity combo will no longer match with what iCloud expects. (not sure if this is part of Octagon Trust, but there are various interesting layers to this)
There are a number of much more in-depth technical guides and specs, but just listing out random articles (or the Black Hat talk(s)) would probably rob someone of a nice excursion into platform security.
Forgetting what the password is because you always just use the fingerprint reader…that’s why for elderly family members I nowadays set it up not to use the fingerprint any more. I thought they’d be annoyed but funnily enough they experience it as a sense of agency, that they are the one unlocking the computer and are in charge of it.
Based on this description, it sounds like someone walking past your unattended desk and bent on disrupting your day but not stealing your data, could enter in a garbage password into the lock screen a few times and lock you out of your own laptop.
I guess the same also works for cloud accounts as well. I remember, back in the mid-2000s, trying to log into my hotmail account (never having failed to log in before) and getting a "locked out due to too many bad passwords". So someone, only knowing my user account name (which was the same as my email address), locked me out of my own account. The problem was, I couldn't remember what my recovery accounts were (I eventually figured it out).
Heck, once I cycled for half an hour with my iPhone in my pocket, and somehow the phone against my leg was in just the right position that it kept interpreting my leg movements as trying to enter a passcode.
Got home, pulled out my phone, and it had a message that it was locked for several hours due to so many failed passcode attempts. Incredibly annoying.
Still, only happened once in well over a decade of owning an iPhone.
I was mostly frustrated that there wasn't some alternate way of regaining access, like via my Mac or iPad logged in with the same Apple ID. Or that the failed passcode attempts didn't start eventually playing a loud alert sound or something on each failure.
The description is misleading. What made the OS create a new keychain was resetting their login password, not the failed password attempts.
(The login keychain is encrypted using the user's password, so it's reasonable to create a new one when the password is changed - otherwise, you end up in a situation where applications constantly pop up prompts for a password the user doesn't know every time they try to access the keychain, e.g. to load saved passwords in Safari. I've seen this happen on older versions of macOS and it's positively infuriating.)
Remember entering password to one service I subscribed to. It was Friday evening. I typed it wrong 5 times and my account was locked out with a message to contact customer service. Customer service was open from Monday to Friday 9am to 5pm. So I was unable to use it for a couple of days. It was painful experience. I found an alternative though and on Monday cancelled it.
Keychain is one of the worst APIs on Apple platforms, with parts that date all the way back to MacOS 9. It's not surprising there are various breaking bugs from decades of low maintenance.
Apple Keychain has a number of old bugs that have caused me to have to resort to this strategy several times. The most common problem is having a secure note that you can open, but then immediately disappears (closes). Copying over an older keychain database can sometimes solve the problem.
Is there really no supported model for this scenario? Surely the point of an iCloud backup is that you can restore from the cloud rather than do a local hack to try to regain access to locked keychain db.
What happens if you just set up the device as a new machine and login to your iCloud like normal?
there are some different options depending on settings - apple will encrypt to an internally (apple held) key that your iCloud login will unlock under most circumstances. This can be turned off by consumers, and I would expect by IT departments at well.
Good information to have. I was surprised by step 2 though (rm login.keychain-db). How can you be absolutely sure it doesn't contain anything important and you won't need it later?
I'd probably opt for a more defensive action here and just rename it (like the original reset did).
I'm hoping that was just the blog version of what they did (since more succinct) but yes, I have so many "-CURRENTDATE-EXPLAINATION.ext" files for any flat-file databases I interact with (keychain, sqlite, db4, etc). It's saved me more times than I can count.
Going in to fix a service that uses sqlite and seeing 5 other times I recovered data or was making a change is always fun.
> Still, I had assumed there might be some kind of master key that would handle this automatically during a password reset.
This assumption, by a clearly technical person, is a fundamental problem that keeps "the rest of the world" locked in to centralised services where that is true, and where that master key can be used against them by law enforcement, fascist regimes, and surveillance capitalists.
There is a lot of documentation from Apple on how all of this works, but this is indeed expected behaviour. A way to make this smoother would have been:
Check the escalation path of key revocation for example where you don't just have longer time delays but also stricter environments where new attempts can be made (near the end): https://support.apple.com/en-gb/guide/security/sec20230a10d/...There are a number of much more in-depth technical guides and specs, but just listing out random articles (or the Black Hat talk(s)) would probably rob someone of a nice excursion into platform security.
Forgetting what the password is because you always just use the fingerprint reader…that’s why for elderly family members I nowadays set it up not to use the fingerprint any more. I thought they’d be annoyed but funnily enough they experience it as a sense of agency, that they are the one unlocking the computer and are in charge of it.
Based on this description, it sounds like someone walking past your unattended desk and bent on disrupting your day but not stealing your data, could enter in a garbage password into the lock screen a few times and lock you out of your own laptop.
I guess the same also works for cloud accounts as well. I remember, back in the mid-2000s, trying to log into my hotmail account (never having failed to log in before) and getting a "locked out due to too many bad passwords". So someone, only knowing my user account name (which was the same as my email address), locked me out of my own account. The problem was, I couldn't remember what my recovery accounts were (I eventually figured it out).
Heck, once I cycled for half an hour with my iPhone in my pocket, and somehow the phone against my leg was in just the right position that it kept interpreting my leg movements as trying to enter a passcode.
Got home, pulled out my phone, and it had a message that it was locked for several hours due to so many failed passcode attempts. Incredibly annoying.
Still, only happened once in well over a decade of owning an iPhone.
I was mostly frustrated that there wasn't some alternate way of regaining access, like via my Mac or iPad logged in with the same Apple ID. Or that the failed passcode attempts didn't start eventually playing a loud alert sound or something on each failure.
The description is misleading. What made the OS create a new keychain was resetting their login password, not the failed password attempts.
(The login keychain is encrypted using the user's password, so it's reasonable to create a new one when the password is changed - otherwise, you end up in a situation where applications constantly pop up prompts for a password the user doesn't know every time they try to access the keychain, e.g. to load saved passwords in Safari. I've seen this happen on older versions of macOS and it's positively infuriating.)
Remember entering password to one service I subscribed to. It was Friday evening. I typed it wrong 5 times and my account was locked out with a message to contact customer service. Customer service was open from Monday to Friday 9am to 5pm. So I was unable to use it for a couple of days. It was painful experience. I found an alternative though and on Monday cancelled it.
It Just Works™... until you don't want to take the default option. I'm sure your average user would just be SoL if going through this same experience.
Keychain is one of the worst APIs on Apple platforms, with parts that date all the way back to MacOS 9. It's not surprising there are various breaking bugs from decades of low maintenance.
You can also just open the old keychain using the old password.
Apple Keychain has a number of old bugs that have caused me to have to resort to this strategy several times. The most common problem is having a secure note that you can open, but then immediately disappears (closes). Copying over an older keychain database can sometimes solve the problem.
Is there really no supported model for this scenario? Surely the point of an iCloud backup is that you can restore from the cloud rather than do a local hack to try to regain access to locked keychain db.
What happens if you just set up the device as a new machine and login to your iCloud like normal?
there are some different options depending on settings - apple will encrypt to an internally (apple held) key that your iCloud login will unlock under most circumstances. This can be turned off by consumers, and I would expect by IT departments at well.
Good information to have. I was surprised by step 2 though (rm login.keychain-db). How can you be absolutely sure it doesn't contain anything important and you won't need it later?
I'd probably opt for a more defensive action here and just rename it (like the original reset did).
I'm hoping that was just the blog version of what they did (since more succinct) but yes, I have so many "-CURRENTDATE-EXPLAINATION.ext" files for any flat-file databases I interact with (keychain, sqlite, db4, etc). It's saved me more times than I can count.
Going in to fix a service that uses sqlite and seeing 5 other times I recovered data or was making a change is always fun.
> Still, I had assumed there might be some kind of master key that would handle this automatically during a password reset.
This assumption, by a clearly technical person, is a fundamental problem that keeps "the rest of the world" locked in to centralised services where that is true, and where that master key can be used against them by law enforcement, fascist regimes, and surveillance capitalists.