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.<p>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).
The description is misleading. What made the OS create a new keychain was resetting their login password, not the failed password attempts.<p>(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.
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.<p>What happens if you just set up the device as a new machine and login to your iCloud like normal?
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?<p>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.<p>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.
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.