Changing password process
Can we look at improving the password change process?
If someone is on a "change password" web page, 1Password could guess this is the case, and tweak how the Command‑Backslash keyboard shortcut works.
So instead of simply:
- Finding a field that might be for the username, and replacing its value.
- Filling out the first password field with the current password.
- Automatically submitting the form.
We could do a quick check to see if the form is likely a "changing password" form.
It could do this by counting the number of password fields (more than 1 is a good indication), then it could look at the password field names, their labels, and most importantly, if any of the password fields have an autocomplete value of "new-password".
If this is the case, then...
Do not fill in the username (this is really annoying when the change password page includes other fields, e.g. your real name).
Try to guess which is the current password field (for some websites it might not exist, or it might be the last field), where a strong indicator is the attribute
autocomplete="current-password"
.Do not automatically submit the form, but instead show the "password generator", ready for the user to simply press the "Fill" button (or customise the recipe).
Let the user submit the form when they are ready :-)
I did find a similar discussion about this: Why doesn't "Change Password" work faster and smoother, like this.
1Password Version: 6.2 (620012) AgileBits Store
Extension Version: 4.5.5.90
OS Version: OSX 10.11.4 (15E65)
Sync Type: DropBox
Comments
-
Hi, @craig_francis. That's certainly an interesting idea. First, I'll say that there is quite a bit more variety in password change forms than what you're describing. Some require the current password plus the new password twice. Some require just a new password, relying on the fact that you are logged in with your current password already. Some require the old password and then a single entry of the new password. Coupling that with the fact that many sites use multiple password fields in the login process (EFTPS is one that springs to mind immediately.) and that makes it much more challenging to identify password change forms based solely on the presence of more than one password. We already have quite a lengthy battery of heuristics to detect password change forms and even then we still sometimes get it wrong.
That being said, I do agree this could be a smoother process. The autocomplete attributes for password changing would certainly be useful for us to add. More importantly, there are some architectural changes we need to make to move the responsibility for identifying password change pages to the native 1Password application, likely powering it by our form filling brain rather than the browser extension as it is now.
That's all a long way of saying we definitely would like this process to be smoother for you, but it will require quite a bit of consideration and a non-trivial amount of change to the 1Password extension, the form filling brain, and 1Password on Mac, iOS, and Windows themselves.
I hope that makes sense. We definitely appreciate the thoughtful feedback and we welcome any other thoughts or ideas you have. It's passionate users like you that help us make 1Password better every day.
--
Jamie Phelps
Code Wrangler @ AgileBitsref: OPX-1158
0 -
Thanks Jamie,
I suspected it would be a big change, but I really think it's worth it.
And I do agree a password field count (two or more = password change form) is a bit too simple, so there will need to be some more heuristics (where I beleve you have quite a few already).
It might just be that you start by only looking for the
new-password
autocomplete value, as I believe that's how iOS and Chome does it.But one of the main things this will fix; when I'm on a change password form, pressing cmd+\ shouldn't nuke a field that 1Password believes is for the username, nor should it automatically submit the form :-)
Anyway, if there is anything I can do to help, please let me know.
Craig
0 -
Thanks, @craig_francis. You're absolutely right that we need to support these attributes. I'm opening enhancement tickets to get this added in the relevant places.
ref: OPX-1161
ref: BRAIN-1650