Muti page password solution / question [another USAA question]

Hello @kbrock,

You can look at the complete JSON of an item with the following steps. The area you're most interested is an array titled fields stored in a details dictionary.

1. Open 1Password's preferences and switch to the Advanced tab.
2. Enable the option Show Item > Copy JSON menu item.
3. Select the item in question and either use the now available menu option Item > Copy JSON or use the keyboard shortcut ⌘J.
4. Paste into your preferred text editor.

I fully confess I'm very curious as to the JSON of this item but even if we were to communicate privately we would have to take very careful measures to ensure anything sensitive such as your username, password or PIN was completely removed as the JSON includes everything including an item's password history.

Oh and yes you definitely don't want your bank suspending your account. I locked myself out of mine once some time ago and had to wait weeks for them to send the new details by post. That was really annoying.

Hi @kbrock,

I wonder if we'll ever figure out why it worked the way it did. Obviously it would be great if my fears weren't true but one of the developers here has been working on my education of the extension and what I know so far didn't tally with your initial discovery. Anyway, on to your questions.

1. When you ask about a JSON paste do you mean into 1Password? If you do then in 1Password for Mac, if there is a JSON in the clipboard you will find there is a new menu option available to you and it can be found at File > New Item from Clipboard. I think this is what you're asking for but if I'm wrong please let me know.
2. Manually using knowledge of being able to copy a JSON and create a new item but my answer to 3. will probably void this.
3. Both the HTML name and ID attributes have to match as part of the fingerprint comparison. If either doesn't then we fall back on filling by HTML designation (just attempt to fill using the values stored in the username and password fields, completely ignoring the web form details section).
4. Custom sections are just as a convenience for the user, they don't get used in filling at all. I like to add custom sections for security questions or what random email address I used for this site. None if it alters how the Login item fills though.
5. The entire item is described in the JSON so it is equivalent to the item. You may have noticed that the ID fields all have text that looks like opid=__20, this is something added to the field by our filling mechanism when it analysed the page. I use this as an example of how the item/JSON is an enclosed item. By doing so it should mean the items fills the same way on other devices.
6. The backupKeys entry relates to attachments I believe. I would recommend not altering that.
7. The UUID is indeed a simple internal ID to identify a unique item in your vault. It's what allows you to duplicate an item right down to the title but still have 1Password tell them apart. It's what the entire merge/synchronisation behaviour relies on.
8. The HTML name and ID do both form part of this fingerprint that has to match the page we're filling. If that tuple matches for each field we fill by HTML attribute (use the web form details section).

I shall pass on the request for table formatting as I can see how that would be useful. We currently outsource hosting the forums though so we can't directly alter that but the company seems to have always been receptive when we've contacted them :smile:

I hope those answers helped. If you wish for me to expand on any particular point let me know.

Greetings @kbrock,

I confess I never did see 1Password 3's filling in action. I was a user but I was awkward and was an Opera person. 1Password only gained support for Opera when they switched to using the Chromium code which is oddly the same time I moved browsers.

I would agree that filling does seem to be more cautious now. This can be open to debate as I don't see it as a crucial security thing. Obviously we want to be careful that things are only filled when they should be. I wasn't part of the AgileBits team during 1Password 3 or the development of 1Password 4 so I'll have to ask around as to the reasons behind some of these decisions and how set in stone anything is.

Currently updating a Login item only affects the password field. So if a page changes at all you're right, we often do recommend attempting to create a brand new Login item which will capture the new page. I personally filed the feature request to see us alter this to update all fields. Unless there is good reason that I'm missing I too think this would be an improvement. ref: OPM-2708

Funnily enough I've been wondering about the idea of storing multiple pages due to the increase in TOTP. At the moment the trouble with TOTP is the first page will ask for a username and password and that's easy no matter what we do, in the vast majority of cases one will be a password field - nice and easy to spot. The TOTP field will, depending on how the site has set it up, either be a text input field or password input field, both of which are used for requesting a username and password. One way around that would be to store the page that asks for the TOTP so that like the original page we can then flag a certain field as being the TOTP field. This would requiring mucking with the format a bit and would not be backwards compatible at all, probably part of the reason why we've avoided it. There is also the question of complexity. We want to support power users but we also have to be careful that we don't make 1Password unfriendly for those not wishing to delve into the guts. I'm sure you would agree that can sometimes be a delicate tightrope to get right. Of course the goal is to always improve 1Password and accept where things could be better. That's one of the reasons I love the forums :smile:

Some of your thoughts only make sense if we become more relaxed with regards to filling. I would expect incremental steps here, first we'd need to introduce this more relaxed filling behaviour and then your other ideas could be explored. We don't want to make things too general though as all sorts of weird behaviour could be observed.

The other consideration is how often much of this would be required. I do believe being able to have 1Password update a web form details section would be very useful and quite possibly more intuitive for many than what we have now. The vast majority of sites though wouldn't benefit from much of this. I'm not trying to come across as being cold at all to the idea but part of the cruel reality is that all software companies have to justify much of what they do at various levels. Developer time is a finite resource and to has to be focussed where it can do the most good. We account for factors such as demand, impact and developer require to complete. I don't state any of this as a way of saying no, I just want to explain why it may not happen. Every idea is considered and some are repeatedly raised to ensure the developers understand our user's desire to see it happen :wink: I suspect though that we could spend lots of time doing all sorts of crazy stuff here for our power users but in the end most sites wouldn't have need for it.

I love your zeal, but imagine somebody else coming along and reading this thread, somebody who can happily use a computer but sees it merely as a tool for certain tasks online and pays attention to it no more than needed. We all know a plethora of people like this. I know somebody who phrases it thusly "I pay you so I don't have to care or waste my time with that machine" :tongue: They'll read this thread and then likely follow hawkmoth's post.

Lots to digest though and it will be interesting to see how we can improve on what we already have :smile:

Please don't take anything here as a reason to not impart your thoughts, you and everybody like yourself who communicates with us in the forums helps to shape 1Password,