Generate password behavior: different in browsers vs. standalone app and Mini

Tonetony

I like to generate pronounceable passwords to do things like answer security questions on web sites. So, I want to clarify how and why the various tools work the way they do.

It seems that the browser extensions (Mac and Windows) will save a new Password as soon as it is copied to the clipboard - even if you drag-select/copy it rather than click the button (labelled Save and Copy (Mac), or Copy (Windows).

But in the standalone app/Mini, you can generate a password, select/copy it to paste it somewhere, then Cancel.

I hope I got that right, as I'm messing with 6 tools (Mac: Safari, App, Mini; Windows: Firefox, App, Mini). (Not presently investigating with iOS, though that would be another I could look at.)

Is there a current rationale for the difference?

I can invent one, but wanted to ask:

My thought is the browser extension, being opened while you are on a web page (technically, though it could actually be a FF settings page, a blank page, or Safari bookmarks or history) is cautious about the risk of generating a password that gets pasted into some field in a web site, but then lost track of. So the moment you copy a password, no matter the method, it gets saved. (Maybe even saved first to avoid any risk at all.)

But the app/Mini are standalone, and, though the same risk actually exists depending on what you then do with the generated password, those tools are apparently less cautious about this, being technically independent of any web page.

The way the app works can be convenient - copy a password, paste it into a Login field or wherever you want to use it; regenerate and repeat; then finally cancel without ever saving (and then trashing) the unnecessary Password.

(In theory for something like web site security questions, you could save a Password for each security question, and link it to the Login, but I think that would be overkill. I would just create a Section of labels and fields for the questions.)

So that's my theory. But maybe it's a simpler reality, that you're just gradually working towards consistency, and it takes time to sync features when you are dealing with so many editions of the product.

Hope you can shed some light. None of this is essential to anyone's understanding of how to actually use 1Password, but understanding rationales helps me learn what to expect and how to select the best tool for my purposes.

Thanks.

---

1Password Version: 7.3.2
Extension Version: 7.3.2
OS Version: macOS 10.14.6
Sync Type: 1Password

littlebobbytables

Hello @Tonetony,

You're right that using the password generator from within 1Password mini will always create a Password item and for the reason you supplied, it is a safety net in case the extension does not detect when the new password is submitted. Many users don't know 1Password does this in the background (the saving of the Password item) because if 1Password does correctly detect and prompt to save/update 1Password will delete that Password item once the Login item stores the same password.

As you've noted you can use the password generator from within the item edit mode and it won't create Password items but the difference is here you need to explicitly cancel edit mode so you're instructing 1Password not to bother saving anything. As there is the action on the user we don't need the safety net, not like with 1Password mini where it is designed to disappear once you complete the action.

While you could create separate Login items for each security question I do as you do and use custom fields. I set the field label to the question, set the field type to password and then set the field value to the reply. As I haven't come across a company where I would need to supply the answer to a security question over the phone I don't use the word generator but do limit the password to only alphabetical characters. Having read your forum post I'm thinking I may adapt my approach here. A collection of random words is just as secure and should I ever need to confirm my identity over the phone a lot less awful :)

Tonetony

Thanks for the comprehensive answer - makes total sense.

And you are exactly right about that identity confirmation over the phone. I was recently asked by some support representative to verify my identity using one of my secret questions, and before I answered, she thought that what she was looking at on her end was corrupt data. She was shocked when I read back the gibberish to her! (The password generator I had used for that didn't have an option to generate a pronounceable string of words, though there was no reason I couldn't have done it off the top of my head. Didn't think of it.)

I call these security questions "insecurity questions" and tend to skip them if I can, but many sites make them mandatory. The VERY WORST not only give you the canned questions to choose from, but also make you select from a list of canned answers! Unbelievable.

Lars

@Tonetony - heh. Yep. Those are truly awful. And they're still out there. The good news is that such sites are getting considerably less frequent, rather than more (or even just staying at roughly the same level). Website owners - especially those with a business reputation to uphold - are becoming more and more aware that their users' experience with their websites is every bit as valuable as any contact they have over the phone or even in person with the business.

(and yeah, my mother's maiden name is =-Toc+C@votU3HrQ3%FMBmNYA, too) ;)