Discoveries with Apple’s Password Manager
Part 1: Why I use iCloud keychain
Apple’s password manager, iCloud Keychain, is an interesting tool that I’ve found works better than anything else for me. It natively knows how to suggest secure passwords, and natively syncs them across all my iThings. When a website texts you a verification code, that’s automatically picked up in iMessage forwarding, and supplied to the browser too.
It’s not perfect. For example, MacOS desktop apps (like Zoom, or Pandora) cannot be auto-filled. You need to go into Safari’s preferences (or System Settings in Ventura) and copy/paste them. In iOS, this is less of a concern, because the password manager is tied to the keyboard.
Since MacOS Ventura and iOS/iPadOS 16, the ability to do TOTP (ala Google Authenticator six-digit codes) has been added, and those sync across all your devices as well. Finally, there’s a new feature called “Passkey” which is based on the WebAuthn standard, and eliminates passwords entirely, similar to how an SSH key works for SSH authentication. This is an oversimplification; I won’t be talking about passkey much in this article, but it shows that Apple is committed to supporting a lot more than the 50-year-old-user-and-password dance.
I use iCloud Keychain versus some other password manager because I believe Apple thinks a *lot* about security. The potential cost to them of a breach is *huge* — and they’ve taken a strong stance on protecting user privacy. And again, that integration is solid. Having to open a secondary app to do things just feels…less sexy. Using the password manager built into Chrome feels disjoint — I trust Google less than I do Apple. Google gives me free mail so they can sell me ads. Apple gives me iCloud because I buy their hardware and pay for both the hardware and the service. In one of these, I am the product, and in one, I am the client.
Part 2: Apple’s Password Monitoring
One of the things iCloud Keychain does is warns you if your passwords are “bad” in some way: easily guessed like (123cookie), repetitive like (foofoofoo), or have actually appeared in a data breach. They do this by comparing your known passwords (on device) to lists of known passwords which are downloaded regularly to your machine — or by comparing hashes of your passwords against hashes that have appeared in breaches. If you’ve used the website haveIbeenpwned.com, it’s a similar idea.
(Apple describes the process here: https://www.apple.com/legal/privacy/data/en/passwords/)
Let’s talk about Apple’s “security recommendations” a bit. They are roughly grouped into two things: breached passwords (which are high profile recommendations that you should do right away, if you do anything at all), and then a list of “oh yeah, you should probably fix these too”.
Recently, I found that one of my “default throwaway” passwords had been in that list. I also had a “finance password” that was a relic from when I didn’t have a password manager, and that had also appeared in a breach.
The problem is: Apple doesn’t grade those passwords. It doesn’t know that you have a throwaway (but breached) password like “stoner123” that you share with your friends who mooch off your Netflix account, and how that’s very different from your breached bank password which requires a phone call every time you log in from a new IP. It doesn’t know that the password you use for the proliferation of phpBB sites out there is NOT the one you use for your IRS login. It doesn’t grok that Mailman not only needs a password to add you to a mailing list, but will regularly mail you that password in the clear, and there’s little harm in just using a dictionary word. A breached password is really bad, deal with it now; any other simple, repetitive, or reused password is just “regular bad”.
And so, to keep the “really bad” ones meaningful, I had to fix them all. I had to change 200-something passwords on 200-something sites. This is the story of what I learned.
Part 3: Fighting with Safari
One of the features in the password recommendations is to take you to a special, de-facto website URL that websites can define to change your password. (It’s listed in the References at the end).
My experience has been that Google does this (it was brought about by Chrome), Apple does it, and literally nobody else does. And the password helper doesn’t even check to see if it exists. It just tries it, and if the site throws a 404, then you get a 404 page. Or a redirect to their main page. Or something else entirely.
Worse, is that sometimes, Safari will helpfully suggest a new secure password, and then NOT ask you “hey, do you want to update your saved password for this site”. Sometimes it will somehow “get” that you’re doing a password change and update itself without asking you. And it’s a crapshoot. Sometimes it does, sometimes it doesn’t. And there’s no way I’ve found to just look up a list of “recently generated passwords” so you can try them out. Sometimes, Safari would ask me, but not until I had navigated to a new URL. (Like, clicked back to a page’s home screen).
I’ve probably changed passwords to Safari’s new suggestion on twenty sites, only to find that Safari could not log in with whatever it had, and had to just do a reset.
Also, nightmarishly, sometimes, Safari has a saved password for a site that no longer exists, or no longer has a user login function at all. Does that mean it’s wiped away forever, or is the database just dormant, but still accessible if someone manages to compromise the box it’s hosted on?
Part 4: Fighting bad web design
Sometimes, I hit a snag that wasn’t safari’s fault.
One thing I’ve learned? The option to change your password is all over the damned place on every different website. It was, on many sites, way way harder to find than it had any right to be.
Further, some sites just plain break when Safari auto-suggests a password — something about the Javascript they use to validate input is just broken somehow. Some will let Safari autofill it on one box, but not on the confirmation box.
Some sites, like Optimum Online, decide that they don’t like special characters in your password, or they only like *some* special characters but not others. There’s no HTML meta tag that says what character classes are allowed there, and maybe there should be.
Some websites change your password and leave you logged in, and tell you your password was changed. Some just return you to the preferences screen. Some immediately, on success, just log you out of just that one session. No “your password has been changed” message, just a login prompt. Others log EVERY session out, on every device. (To the appropriate panic that I might not be able to log back in). Some sites email me to let me know my password’s been changed, some do not. There’s zero consistency.
Part 5: Room to Improve
So, here’s the laundry list. For Apple:
- Every time Safari suggests a password, log it somewhere, just in case Safari missed the form submit.
- Make the password changing experience more fluid. Give users the ability to feed back when a site doesn’t work right. Give even more options, like “pronounceable” passwords. There will always be *some* passwords which we will just have to type in sometimes (like the ones for streaming media services. Don’t make it painful.
- For some cases, Safari will be unable to tell that two sites are the same entity (for example, machines I have connected to via both IP address, and hostname). I can edit usernames, and passwords, but I cannot edit *site names*. This feels like it needs to be fixed, because otherwise, a password looks “reused”. Maybe this is just a sysadmin problem, but maybe it’s not. For another practical example, my Scottrade password was “reused” on TD Ameritrade, when Scottrade was bought out. Merging things and saying “no, these are the same thing” feels useful.
- If you’re going to tell me my password was seen in a data breach, could you tell me when it was first seen?
And for everyone else, a rant: Have you ever noticed that credit card terminals work wildly differently from each other? With some you have to wait till the transaction is totaled before you can put your card in, some you can put your card in every time. Some, you have to tell it “debit”. Others, you just hit cancel, others you just hit enter for no PIN. These are machines that pretty much EVERYONE has to interact with , and this disjointedness feels woefully broken.
The password changing experience is the same way. Somebody, anybody, please write a NIST-level standards document about how this should work, so I can point people at it. Your websites are not just used by trendy people who grew up using this stuff— they’re used by seniors, and dyslexic people, and people who do not have English as a first language, and people who are using assistive screens and screen readers.
While we’re at it, and while we’re defining a better experience for changing passwords, let’s come up with a standard well-known URL for resetting them as well. Even if that reset process is just a webpage that says “sorry, call our customer service number”.
This is literally *the most basic and important* function on your site — the one that stops other people from seeing your PII when there’s a problem. Don’t fuck it up.
References:
https://w3c.github.io/webappsec-change-password-url/ The spec for the standard for password-changing URIs. It’s a fairly new standard (2021), but there’s literally zero reason it can’t be implemented everywhere.
https://firewalltimes.com/apple-data-breach-timeline/ A listing of all Apple software breaches, lest my stance make it seem like they’re too perfect.
https://password-managers.bestreviews.net/faq/which-password-managers-have-been-hacked/ A listing of other password managers which have had security issues or breaches in the past.
https://www.upguard.com/blog/this-password-has-appeared-in-a-data-leak is a bunch of common-sense advice that I find reasonable, for dealing with this feature.
