Filling dropdown field only working on new items

Hey,

It looks like the fill of a dropdown field on a Fritz!Box only works on items created after filling the login page (and saving it from that)

The webform-details say the exact same information as the one created a long time ago manually.
Which makes it a little bit odd that it doesn't work.

Also updating the item doesn't work.
So, is there any possible way to get this working on old items, as I don't really want to loose my password history? :unamused:

As always thank you for that great product and your help :chuffed:

~lumarel


1Password Version: latest on Windows and macOS
Extension Version: 5.7.5.90
OS Version: latest stable Windows and macOS
Sync Type: Dropbox

Comments

  • ag_yaron
    ag_yaron
    1Password Alumni

    Hey @lumarel ,

    We need to clarify a few things here in order to understand your issue.

    • What's a Fritz!Box? Am I correct to understand it is a router? Does that mean you cannot provide me with a link to test its login page?
    • Which version of 1Password are you working with? 7?
    • Which operating system are you on? Which browser and 1Password extension version are you using?
  • lumarel
    lumarel
    Community Member
    edited May 2020

    Hi @Yaron,

    Thanks for your reply!

    • Yes, a Fritz!Box is a Router including its OS called Fritz!OS, sorry forgot that this is not really known outside of europe
    • As I mentioned in the details it's the latest version for Windows (7.4.767) and the latest version on macOS (7.5)
    • The operating Systems are also the latest available in the stable branches (Windows 10 1909 18363.836 and macOS 10.15.4)
    • Used browsers are:
      • On Windows: Firefox 76.0.1, Firefox Nightly 78.0a1 and MS Edge 81.0.*
      • On macOS: Firefox Nightly 78.0a1

    To understand it maybe even better the complete exported configuration of the two items:

    • working item:
      uuid=<censored>
      title=Fritzbox
      category=001
      scope=Default
      autoSubmit=Default
      tags=Homenetwork/Network
      website=https://<IPcensored>/
      website 2=https://fritz.box/
      uiPass=<censored>
      one-time password=otpauth://totp/<censored>
      This has been generated with the autocreation feature of the latest 1Password version for Windows, which asks if you want to create a item of the entered login data

    • not working item:
      uuid=<censored>
      title=Fritzbox 2
      category=001
      ainfo=lcla
      scope=Default
      autoSubmit=Default
      tags=Homenetwork/Network
      website=https://fritz.box/
      website 2=https://<IPcensored>
      website 3=https://<IPcensored>/
      previousPassword1=<censored>
      previousPassword2=<censored>
      previousPassword3=<censored>
      previousPassword4=<censored>
      uiUser=<UserCensored>
      uiPass=<censored>
      One-Time Password=otpauth://totp/<censored>
      This has been created with 1Password 4 for Windows, so a really old item

    As you can see it has at least the same properties, but only the autogenerated one works:

    The real problem here for me is, that it is also not possible to fix the not working item by updating it, only creating a new one works 🤔

  • ag_yaron
    ag_yaron
    1Password Alumni

    Thanks for the detailed reply @lumarel .
    Although you censored the important information, I'd suggest removing it completely so it won't be visible here at all.

    The only difference I'm seeing is that the old non-working login has a username field and the working login does not, so that's a good starting point. Try editing the old login and clear out the username field, then save and test.

    Keep in mind that autofilling is something we constantly change and enhance/improve, and there's a big difference between 1Password 4 and 1Password 7 on that aspect.

    Another thing I'd suggest you test is what actually being autofilled into that password field. Disable the auto-submit on these login items so 1Password won't log you in immediately after autofilling, then try to autofill. Once the password is entered into the field, right click it and select "Inspect", then in the HTML code that shows up change the field's type from type="password" to type="text". That will reveal the password in the field and you'll be able to compare and see what is wrong with it.

  • lumarel
    lumarel
    Community Member
    edited May 2020

    No problem @Yaron,
    thank you for the tipp, I completely removed all user-specific data now, so if somebody finds this has at least something to see :chuffed:

    I did also the removal of the username of the not-working item, but that didn't help, because it kind of completely removes the username (as you may have seen in the working item the username was mentioned as uiUser in the webform-details, but didn't get exported) :unamused:

    Off course I also already thought about that, but that shouldn't really change anything in the datastructure of the opvault-files right?
    I also double checked the information with 1P4 now, the changed-not-working item doesn't show any username now, but the working one shows the uiUser in the (there editable) webform-details.
    Interesting is also that there is mentioned, that the uiUser is of the type select and does not have the designation username (there is a seperate empty property called username which has the designation username)
    Changing the not-working item to the exact same schema with 1P4, closing and killing 1P4 and open it with 1P7 actually fixes the item!
    So, the correct form, that 1P7/the Companion App for the browser recognizes the dropdown form the Fritz!Box login would be:

    • property username with the designation username has to be a seperate property
    • property uiUser with no designation (only as a webform-detail) has to have the username
    • property uiPassword with the designation password has to have the password

    For the HTML properties:
    As I'm aware of a select element does not have a type.
    But the password, which is a input element has the type password.
    So yeah, on that side I think AVM did everything correctly :+1:

  • lumarel
    lumarel
    Community Member

    Interesting is also that I'm unable to destroy the item after correcting it with 1P4, adding the username to the username field (working) and removing it again does not remove it from the webform-details. Looks like the link between uiUser and the designation username was the problem.
    After unlinking these two properties everything works!

  • ag_yaron
    ag_yaron
    1Password Alumni

    Hey @lumarel ,
    I'm glad I was able to point you in the right direction. Well done there :)

    You can basically build logins manually by adding custom fields that have the same HTML name as the fields on the website and the same type (e.g. a text field or a password field...), without using the "official" username/password fields in the login item or the saved form details, but I'm glad you found a way to make it work with your old item.

  • lumarel
    lumarel
    Community Member
    edited May 2020

    Hi @Yaron,
    thank you for the help ^^

    Ah thanks for the additional explenation :chuffed:
    I would be really happy if I wouldn't have to go back to 1P4 every time something like this happens, I know I'm asking for quite much with this, already had multiple discussions with Mike about this, but I would be really happy if this feature (adding/removing additional fields, as well as linking/unlinking the official field designations) would be on the top of the bucketlist some time in the future :chuffed: :+1:
    And maybe it is possible that the application would be possible to change the custom fields as it updates the item, because that was the main problem in that case, it couldn't split the username designation from the custom field ^^

    I'm speaking about 1Password 7 for Windows here, as this is already possible in macOS! I just use Windows as my primary OS, and because of that I didn't really recognize that this is possible in there 8-) (I use the macOS application mostly only as a reader ^^)
    On the macOS side I have to point out that the type is shown wrong, select is shown there as text 🤔

  • ag_yaron
    ag_yaron
    1Password Alumni
    edited May 2020

    Thanks for the feedback.
    I doubt this will ever be implemented/improved, we actually want to get rid of the saved form details because we don't want users to have to deal/mess with it. We want 1Password to do its job without users' manual interaction :chuffed:

    The main thing here is that your need is quite unique. You want to keep the old logins from 1Password 4 because you don't want to lose the passwords history in each item. I have never heard that before. In every other instance the solution would be as simple as capturing a new login on the website and it would work (and it does). So I'm afraid you'll either have to keep editing in 1Password for Mac for the time being, or simply create new logins for these websites (honestly I'm not quite sure what are the benefits of saving the password history?).

    I hope that clarifies it, it's important for me to be honest and not giving false hopes, although your feedback will be useful when we discuss the saved form details next time. So thank you again!

  • lumarel
    lumarel
    Community Member
    edited May 2020

    You're welcome @Yaron :chuffed:
    I did notice that over the past two years really clearly, but we also got to the point, where we are also possible to edit webform-details in 1P7 for Windows 🙂 so my hope isn't fully gone up to now ^^
    Of course it would be really great if 1Password knows for every web-based service the right form to insert the credentials correctly, but up to now I know so much services which are not publicly available and also have there special characterstics, because their devs thought thats the best way. As well as services which are constantly changing their pages :unamused:

    I know I'm not quite the general user.
    Have multiple offline/dropbox vaults with hundreds of old as well as new items, which are at least a third internal services (domains, databases, web-based services, monitoring, ...). And because of that it is totally okay if you just say that shouldn't be the main use case, and because of that the development focus is on other parts.
    And that's of course good, because I also really like i.e. these massive performance improvements! (and the drag and drop feature this brought my workflow to a whole new level :) )

    The reason I really like to keep the password history mostly is because of backups, disaster recovery and so on, when you recover a machine or cloned it for a testlab, suddenly you changed the password and because of the length you couldn't remember the old one, here come the old passwords in really handy. (there were also other more bad practice cases, but these are the major ones)

    So, really no problem, this is always just a request, and if it doesn't fit to your / the whole teams concept for the future plans, then it is also okay. I'm already happy to be allowed to contribute :chuffed: (please just don't remove the offline/dropbox sync "again" I'm not really a fan of giving my data to a specific webservice, which of course is meant to be really save but also because of the only use case a more attractive target)

  • ag_yaron
    ag_yaron
    1Password Alumni
    edited May 2020

    I really appreciate your spirit here, @lumarel .
    Thanks for all the feedback and info.

    You do have a very special use case here and I'm glad you see it as such. I do hope we will be able to improve things in the future to a point where the web form details are no longer required, but I think that is not a near-future goal as of now. Perhaps our developers will decide to improve web form details in the meantime, who knows? Never say never eh :chuffed:

    I also don't know of any plans to remove iCloud/Dropbox syncing and I don't think it was even an option for us. We know some users want their data in their own places and spaces, so that is always an option. Regarding your security concerns, I had the same ones until I read and understood how 1Password and the membership cloud service works. It is literally unusable to anyone but yourself. We strongly believe in the saying "You can't lose what you don't have", and what we don't have is your Master Password or Secret Key, which are both used to encrypt your data in a manner that is virtually impossible to crack with today's technology. We can't read your data and that means no one else can, even if our servers are breached, your data is encrypted in a manner that makes it useless to anyone else but yourself.

    It is quite a big and different subject so I don't want to discuss about it here to prevent diverting this forum post's original subject, so I'll just direct you to some of our articles for more info, if you're interested:

  • lumarel
    lumarel
    Community Member
    edited May 2020

    Ah thank you for the additional info @Yaron!

    Let's see what the future brings, I'm sure it will get at least even more polished :chuffed:
    And I'm pleased to hear that the opvault integrations won't disappear (with a lot of luck Apple extends the CloudKit, or what component your iOS app was using, to other cloud services, so we are also possible to use other clouds like OneDrive or even a self-hosted one) ^^
    At least for the corporate environment I will always need them, higher security standards (and SSL inspection which definitely kills the sync) make it the only possible option

    I have to admit, that I have already thought several times about switching to the subscription with your own cloud service, so I already read everything up to the White-Paper :+1:
    My mindset with the dedicated cloud service is just, if there is a bug (we are all humans so that could happen) it is more likely, on a dedicated service, that somebody tries to exploid it, than on a general storage cloud service (with the intend to find password stores).
    But yeah... this mindset fades with the time because of Dropboxes rising limitations. (On Linux it got really bad, up to now)

  • ag_yaron
    ag_yaron
    1Password Alumni
    edited May 2020

    Your general thought process is correct and understandable, but let's take a look at a few facts:

    • Other cloud services have all been hacked/exploited before, we haven't so far (which I'm impressed and proud to say).
    • Even if we do experience a breach and data is stolen from our servers, it is all encrypted and the data is useless. It is virtually impossible to extract readable data without your Secret Key. We can release all of the data on our servers to the world right now and your data will still remain safe (but of course we won't :tongue:)

    The combination of your Master Password and Secret Key creates an extremely long, random and complex password that is needed to decrypt your data, which is the base on which our entire security model is built on. That, and the fact that we don't know or store any one of these two, so no one can get them from us.

    By the way, you can store a local vault on your computer, then move it to any other cloud service you want (Google Drive or OneDrive etc) and point 1Password to that location (if it creates a local folder on your computer). That will work, but keep in mind that local vaults (and Dropbox/iCloud vaults) are only encrypted with your Master Password, so the security of your data relies on the strength and complexity of your Master Password alone.

  • lumarel
    lumarel
    Community Member

    Hey @Yaron,

    Sorry for the longer delay, had some rough days.

    I wouldn't take the strong word "all", but yes there were a lot of hacks and data thefts up to now :unamused: This is what makes me a little bit confident that my data could be safe in your services.
    But at the same time this could also be attractive for somebody to try even harder and be the first one ^^ (but I have to admit its gonna be really hard for them ^^)
    The thought is just, if somebody searches for secret data of somebody they will definitely find it there, because of the dedicated service.

    Extremely long and komplex password is always good to have, but for comparison (I know these is not a really good ones) e.g. SHA1 or WPA were also some really good encryption methods some time ago.
    But I understand what you mean, and it will definitely be nearly bulletproof for a longer time :+1:

    Yup, thank you for pointing that out! I'm actually doing that with a local NAS system without any cloud service, the only problem there is, that iOS can only reach local vaults with Dropbox (or iCloud Drive but that's a little bit hard for me to implement in my current system configurations) :chuffed:

    ...you're definitely motivating me with this discussion to really think about switching (and doing the math if the additional features value themself) :+1:

  • lumarel
    lumarel
    Community Member
    edited May 2020

    So... I made it now through the whole white paper now.
    The concept seems to be really bulletproof, or at least has so much security enhancements, that it should be impossible to get the credentials out if you don't have all the keys.

    Maybe I didn't fully understand it or just have missed that but I have two questions:

    • What's about companies which have implemented SSL-inspection? There is mentioned that HPKP isn't implemented up to now, but will be in the future. Does this mean a connection through a NG-firewall with SSL-inspection will be possible now but might not be possible in the future?
    • And, what about local backups? I would really like to make a automatic local backup which is encrypted but could be decyphered without the cloud service. Is this possible, because I couldn't find this in the white paper or on the help page?
      Up to now I did this by making automatic (extra) backups of the appdata_local backup folder, which are basically the opvault directories in a zip file.

    These two would be the only blockers for me up to now for switching ^^ (mostly the second one, because I can live with the constant errors in the debug log, that it couldn't sync)

  • ag_yaron
    ag_yaron
    1Password Alumni

    Hey @lumarel ,
    I'm glad to hear you're doing your research :)

    SSL-Inspection is not a threat, because we don't send anything important/decrypted over the network when you log into your account. The entire decryption happens locally on your device/browser.

    Regarding local backups, you can add a local vault to your 1Password app that will be stored locally on your computer or on iCloud/Dropbox, and backup by copying the contents of your 1Password.com account vault into it. That local vault will be encrypted with your Master Password locally wherever you save it. Another way would actually be as you did up until now - by backing up the 1Password's data folder.

  • lumarel
    lumarel
    Community Member

    Okay thank you for the help @Yaron :chuffed:

    I didn't think something else about that but thanks for confirming :chuffed:
    Hm but the general problem with SSL-inspection (or with the full name SSL-deep packet inspection) is that it breaks the packet open and then signs it again with another certificate, which means HPKP won't work :unamused:
    (we had it once before that c.1password.com was on the major firewall autoblocking list as well, whyever)

    Ah that's great if I'm possible to sync the items of the 1Password.com account to a local vault, is there an option to do that automatically because backups shouldn't really be a manual task ^^ (I couldn't find this up to now)
    You mean backing up the sqlite database? Yeah that would also be an option :+1: (The problem here is, that the database is version-dependend and the opvault is also usable without the 1Password app, meaning you can decypher it quite easily with your own or somebody elses script like done in the unofficial clients for linux)

  • ag_yaron
    ag_yaron
    1Password Alumni

    I don't think SSL inspection has any effect on how it works, but I might have to call one of our security team members to chime in here for a clearer answer.

    There's no way to automatically create such backups because:

    • Your data is backed up in your 1Password.com account. So in case you experience data loss, you simply log into your account on a new setup and all your data will be downloaded to the device immediately.
    • Your data is also locally available on each device that the 1Password app is installed, so if our servers are down, you still have full access to your 1Password apps and your database.

    Any backup needs beyond that will have to be made manually by you (or automated with a 3rd party software). I do feel like it is an overkill to perform yet another manual backup. What are the odds of you losing your local data and our servers are offline simultaneously?

  • lumarel
    lumarel
    Community Member

    I don't really want to overcomplicate that SSL-inspection topic, but that could be a concern for some companies, because it's a widely spread technique, which a lot of bigger companies use to secure their networks.

    Yes, I know I'm kind of making that more secure than maybe needed (up to now I have 2 extra backups of my dropbox, so there are cloud -> hot-local with snapshots -> cold-local, as well as the backups from 1password for every day if changes are made, which are saved on an additional drive), but these are all my credentials for everything, I don't even want to think of loosing them.
    But I will have a solution for that now :+1:

    So, I think that's everything then, these are no blockers anymore.
    Sorry for stealing so much time about that :unamused:
    And thank you for all these answers :chuffed:

  • ag_yaron
    ag_yaron
    1Password Alumni
    edited May 2020

    Thanks for that followup @lumarel .

    I asked out security team and found that HPKP is deprecated. Has been that way for quite some time now, so that's out of the question.
    They also said that Deep Packet Inspection doesn't work on SSL encrypted traffic.

    If you're on a corporate network with MiTM/proxy, then yes, your traffic will be intercepted, not much we (or any other password manager) can do about it, but even so, that's what SRP (Secure Remote Password protocol) is for, so we don't have to rely on the integrity of SSL.

    I also heard we do have some possible features in store regarding that local backup solution, but not much info (or timeline) is available on that at the moment.
    I'm glad I was able to help!

  • lumarel
    lumarel
    Community Member

    Ah that was the answer I was searching for :+1:
    Thanks @Yaron

    Because in the White Paper on page 53 there is mentioned that Certificate pinning isn't implemented up to now, maybe it's time to update that some time :glasses:
    (Deep Packet Inspection only works on SSL traffic if the packets are signed by the firewall, so yes this is playing MitM, ref: Cisco Firepower, but that's kind of the way to go nowadays... makes a lot of problems with non-managed-Certificate/Keystores, but yeah)

    Oh that's cool if it's even already on the Backlog, I have a possible solution for now but an automatic (backup-)sync to a local opvault would be much appreciated :chuffed:

    So, I'm now onboarded to a 1Password.com Account, finally :wink: (the process was so easy, just login and share->move, god if everything could be that easy :scream: )

  • lumarel
    lumarel
    Community Member

    Using a local opvault as a manual backup solution isn't possible by the way because some of the items have attachments :unamused: (at least database-backuping works)

  • ag_yaron
    ag_yaron
    1Password Alumni

    I'm glad to hear you started a family account! Welcome aboard :chuffed:

    Yeah, items with attachments can't be copied with the attachments, so hopefully an automatic backup feature will be available in the near future.
    I'm glad I was able to help out!

This discussion has been closed.