Getting your password manager to save the right password

A password we can’t reset

Your Bracemark password does more than sign you in. It unlocks the key that encrypts your library, and we never have it, so we can’t reset it. If you lose it and have no recovery code, nobody can open your library again, us included.

That makes the copy in your password manager more important than usual. A missing copy is a problem you notice. A wrong one is worse: you trust it, sign out, and find out months later on a new phone that it doesn’t open anything.

Password managers decide what to suggest, save, and fill by reading the form. Each one reads it differently, and none of it shows up in our tests. The offers are browser or system windows outside the page, so a form can pass every test and still leave the wrong password behind.

So we measured them. A script reads Chrome’s own log of what it detected on each form. We checked Safari and iOS by hand in the iOS Simulator, and Safari for macOS on our staging site. On Android we read the screen description that apps hand to the autofill service, and then tried Google Password Manager itself on the Android emulator. Here’s what that changed.

The create-account form we replaced

Creating an account used to take three steps. You chose a password, then got a recovery code, then signed in once to check you’d saved the password. We created the account only at the end, once the check passed.

Each step made sense on its own. Together, they gave password managers the wrong moments:

• In the iOS app, the password field disappeared when you moved to step 2. iOS took that as an account being created, and offered to save the password for an account that didn’t exist yet.
• Safari took the check on step 3 for a new account’s form too, and offered a new strong password there. Accepting it saved Safari’s password under your username, over the real one, so your saved copy was wrong before your account even existed.
• Going back to change your password, or regenerating one, could leave an earlier copy saved.

Create account is now one step: a username, and a password field that already holds a generated password, which you can keep or edit. The account is created when you press Create account, and only then does the form go away. That’s the shape every password manager knows. Whatever is in the field when you press the button is your password, so if your manager suggests its own strong password, that’s fine too.

Checking the copy after it exists

The recovery code and the check were worth keeping, so they moved after the account is created, to a short welcome. The welcome offers a recovery code first. It then asks you to sign in with your saved password, which shows you the copy works before you need it.

To Safari, that check had to look like a sign-in, and no attribute on the form controls how Safari reads it. The words on the page do. In our tests, Safari treated the form as a sign-in only when the button started with “Sign in” and there was a link saying “Forgot your password?”. Without either one, it offered a new strong password again. So the check’s button says Sign in to check, its link says Forgot your password? Show it again, and a test fails if anyone rewords them.

We also catch the case where Safari offers its password anyway. If the check fails and the browser filled the field itself, the web app offers to use that password instead, as a real password change. Your account then matches what your manager saved.

The save that never came on iPhone

Moving create account to one step was meant to put the save in the right place: after the account exists. On the web it did. In the iOS app, we then found that iOS never offered to save a new account’s password at all, at Create account or at the check.

Create account still gets no offer, and we haven’t found out why. It didn’t matter whether the password was generated or typed. The check was a different story. Its username was a read-only field, and the way our app framework makes a field read-only also disables it. iOS ignores disabled fields, so to iOS the check had a password and no username, and it offered nothing.

The check’s username is now a field iOS can read but you can’t change. When the check passes, iOS offers to save the password, under the right username, and the saved copy signs in. If you skip the check in the iOS app, you get no offer, so save the password by hand.

Whose password is this?

Change password in Settings takes your password without showing your username. Password managers read a username and a password as a pair. With no username, a manager has to guess which saved login an update belongs to.

On the web we give change password a hidden username field. After a password change, Chrome then offered to save the new password under your username.

The apps had nothing like it, and a phone has no hidden field that a manager still reads, so the apps now show your username above the password there, in the same kind of field as the check’s. What that does depends on the phone:

• Android: with the username there, Google Password Manager offered to save the new password to the right login after a change, and the password it stored signed in. Without it, it offered nothing.
• iPhone: iOS reads the username now, but it still doesn’t offer anything after a password change (below).

Passwords that only prove it’s you

Recovery code and Delete account ask for your password only to prove it’s you. Your manager should fill it in, and it has nothing to save afterwards. Delete account taught us the most. You type your password, the account is deleted, and the form goes away. To a password manager, that looks just like a sign-in.

In every case where the manager could tell whose password it was, it offered to save it, after the account was gone. Chrome did, with our hidden username. Google Password Manager on Android did, with the visible one. iOS did when it could read the username. Recovery code got the same offer when the new code appeared, which looks like an offer to save the code. It was your password, but that’s not what it looks like.

So neither screen shows your username in the apps, and your manager still offers your saved password when you tap the field. On the web, removing the username wasn’t enough: Chrome still offered to save the password, now with no name. Both fields now use the same marking as our app lock’s password, which tells Chrome it isn’t a sign-in password. Chrome then makes no offer, and clicking the field still lists your saved passwords.

Safari still fills these fields from your saved passwords, and if your login is saved, it asks nothing afterwards. If it isn’t, Safari offered to save after both screens whatever we marked the field with, and after Delete account that meant a login for an account that was gone. If you see that offer after deleting your account, choose Not Now.

None of this removes the deleted account’s password from your manager if it was saved before. After deleting your account, remove that entry yourself.

What still isn’t right

• The iOS app doesn’t offer to update your saved password after you change it. We tried it with and without a username, typed and generated passwords, and saved and unsaved logins, and iOS never offered. So after a change, the app keeps Show my new password on screen until you leave, for copying into your manager by hand.
• Safari and the iOS app keep separate copies. The iOS app doesn’t suggest a password you saved in Safari, although you can choose that entry by hand. Apple lets an app share a website’s saved passwords, so we built a test version that does. It shared them, but on an empty password field at Create account, iOS offered a strong password of its own. Accepted, it became the account’s password, and iOS didn’t save it, so the only copy was the one the welcome could still show you. We won’t ship that until the iOS app saves a new account’s password at Create account.
• Create account in the iOS app is never offered for saving. The check covers it if you take it.
• Safari offers to save after Recovery code and Delete account when your login isn’t saved (above).
• The apps were measured in the iOS Simulator and the Android emulator only. On a Mac, Safari offered to save a generated password you didn’t edit at Create account, and to update it after a password change.

If your manager offers to save or update your Bracemark password, accept it, then use the welcome’s check, or sign in on another device, to confirm the copy works. Where to keep your password has more on choosing a place for it, and our notes on password managers record every measurement, with dates and versions.