Inactive 2FA Interaction [UX]
Hi, I've been trying to setup 2FA for my accounts using the "Inactive 2FA" Watchtower feature. I have some suggestions for this workflow.
1.) If the user selects "one-time password" in the dropdown, the section name should automatically default to "Two-Factor Authentication" and the label name should be "One-Time Password". I do this every time I set up 2FA and it's a big help to have this automated.
2.) After the user selects "Save", please don't remove the current account in the "Inactive 2FA" group immediately. Usually, sites would request for a code right after the QR code is scanned, it would is confusing at first where the login item went. (Out of the group because 2FA is already active, but confusing, and inconvenient.)
1Password Version: 7.2.4
Extension Version: 7.2.4
OS Version: Mac OS 10.14.2
Sync Type: 1password.com
Comments
-
Welcome to the forum, @jkspn! Thanks for taking the time to come here and share your ideas with us regarding the TOTP feature in 1Password. I suspect we probably won't be doing the first of your suggestions, because not everyone wants things to be labeled the same. That means we'd likely have just as many if not more people writing to us to ask us to change this behavior back (or to something else), were we to do it. Many people don't think "Two-Factor Authentication" is an accurate description of what is actually occurring, for example, since using 1Password as both where you store you actual login credentials as well as the TOTP code means this isn't a true second factor in the way a hardware token would be, and so it's more properly called Two-Step Verification. We could call it that automatically, but that, in turn, might confuse people who've never heard the term before and get confused because they wanted to turn on Two Factor Authentication, not this thing called Two Step Verification. I'm going on at a bit of length here, on purpose: no matter what we choose there, we're likely to be annoying/upsetting a certain segment of our user-base, or, worse, confusing them and sending them down the wrong path. Allowing people to choose their own titles that make sense to them will probably be what we stick with for this.
With regard to changing when an item is removed from the "Inactive 2FA" list, I can definitely see what you mean. What I'm not sure about is why people don't just setup 2SV when first creating the account? Even if you are working from the Inactive 2FA list, you can search for the item, or even just scroll to it in the Logins category, which would eliminate that issue. That's at least what I'd recommend for the present. But I'll definitely share your thoughts with the development team, as you're right, it does add a step. Thanks again for taking the time to share your observations and for being a 1Password user! :)
ref: apple-2696
0 -
You make very good points for my first suggestion. It was just a nitpick—although admittedly with 2FA/2SV turned on for an item the code is simply labeled "one-time password" which is more than enough. Thank you for sharing your thoughts and really taking the time to elaborate the thinking behind this decision.
There are a couple of instances I'd like to share regarding suggestion no. 2.
This is something I have always meant write to you guys about, actually, especially during that brief period were many online applications have implemented 2FA in their services within weeks of each other. Even now, there are some services that have just recently implemented 2FA, so from time to time I do a cleanup in the "Inactive 2FA" list.
I change passwords on a regular basis, especially for important accounts, and sometimes that would require me to disable and then re-enable 2FA. That means I'd have to hunt the login down again, sometimes in the "Inactive 2FA" list.
0 -
@jkspn - excellent point: there has indeed been a gradual and increasing upswing in sites adopting 2FA where previously they hadn't. To let you know (since I wasn't fully clear in my last post), we do indeed have this filed as a feature request already (that's what that small print at the bottom of my post is: our internal number for it: apple-2696). The person who filed that issue is actually the head of our Apple (Mac and iOS) team, so why (you may be wondering) has it not been addressed yet? The answer is: limited developer hours, and a host of higher-priority issues. This is indeed something we'd like to get to in the future, but as of yet we just haven't had the available dev cycles to address it. I'd be lying - or at best guessing - if I said I had any idea when that might change, since our workload varies constantly based on multiple factors. But it is something we'd like to address. :)
0
