KC_BREC Posted June 29, 2020 Share Posted June 29, 2020 We have noticed what we think may be a bug, or at least not working as we intended. We have a password list that is shared but must provide a reason to view the password. This list contains entries that include URLs. These entries show up as usable by the browser extension when visiting the URL in a browser. The browser extension will allow you to use it but does not prompt for a reason before filling the form fields. An entry shows up in the audit log that it was used but that's all it displays. We tried setting the API usage to mandate a reason when using the API but then you can't use the entry at all and the extension never prompts for a password. Is this by design or a bug in the software? Should (or can) the browser extension prompt for a reason before filling the form fields? Link to comment Share on other sites More sharing options...
support Posted June 29, 2020 Share Posted June 29, 2020 Hi KC_BREC, This is be design for our browser extension, and certain Password List settings are only applicable in the UI, and not in other modules like the Browser Extensions. Regards Click Studios Link to comment Share on other sites More sharing options...
KC_BREC Posted June 30, 2020 Author Share Posted June 30, 2020 This seems very counter intuitive. I (and I assume many others) would assume that restrictions placed on the UI would apply across ALL products not just one of them. Might I suggest that for the sake of security and continuity of the product(s) this design be reconsidered? The browser extension does not appear to use the API since the API restriction options available for lists do not have any effect on the browser extension. If this is intended design, then how do we restrict users from using this list within the extension but still be able to access it in the UI? The only work around we have found is to remove the URL field value and instead place the URL in a custom field. Any other options? Are we approaching this the wrong way? On a somewhat related note we also noted that linked entries do not apply the security restrictions of the contained list but revert back to the security settings of the least restrictive list. As an example we linked an entry to an entry with a URL field value to a list without a URL field and the browser extension still recognizes it. Link to comment Share on other sites More sharing options...
support Posted June 30, 2020 Share Posted June 30, 2020 Hello, The browser extensions have been designed to be as simple as possible, without the requirement for user input. As you're the first customer to request this, would you be able to log a feature request in the 'Feature Requests' sections of this forum, and this will allow us to prioritize based on the voting system we have. Unfortunately you cannot restrict users in the Browser Extension, but not in the UI. If you've been given access to a Password List, it will be available in both. With your second query, it looks like you've found a bug for us, as only Password Lists with the URL field selected should be used in the Browser Extensions. I've logged this to be fixed in the next release, and thanks again for reporting it. We'll post back here once the new release is available. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted June 30, 2020 Share Posted June 30, 2020 Maybe we could also exclude Password Lists where the 'Provide a Reason' is checked, but this might upset quite a few of our other customers. Probably best to log a feature request to see how many customers are interested in needing to provide a reason for logging into a web site. Regards Click Studios Link to comment Share on other sites More sharing options...
KC_BREC Posted June 30, 2020 Author Share Posted June 30, 2020 Thanks for the follow up. I have posted a feature request. Link to comment Share on other sites More sharing options...
support Posted July 12, 2020 Share Posted July 12, 2020 Hi KC_BREC, Just letting you know that build 8951 has been released today with this fix included in it. You can follow any of the suggested upgrade methods in the following document to upgrade Passwordstate https://www.clickstudios.com.au/downloads/version9/Upgrade_Instructions.pdf Thanks again for reporting this issue to us. Regards Click Studios Link to comment Share on other sites More sharing options...
KC_BREC Posted July 13, 2020 Author Share Posted July 13, 2020 For clarity, I believe the issue addressed in build 8951 was not concerning credentials in a "Provide a reason" list showing up in the browser extension as they still do appear and work as before, but rather the issue of the security of a credential reverting back to the least restrictive. Per the change log on build 8951: Quote Linked password records where showing in the Browser Extensions when the URL field was not selected in one of the linked Password Lists However, there is now a new issue. I linked a credential from a list with a URL field to a list without a URL field, both of which I have permissions to. Now instead of two entries showing up in the browser extension as before I have none. Should not the one that still has the URL list be showing as I still have access to it? Link to comment Share on other sites More sharing options...
KC_BREC Posted July 13, 2020 Author Share Posted July 13, 2020 Please disregard my previous comment. Not sure what happened, but after I logged out and back into the extension several times it started working as expected. The credential with a URL is now showing in the extension. Thanks for addressing this and sorry for the confusion. Link to comment Share on other sites More sharing options...
support Posted July 13, 2020 Share Posted July 13, 2020 No problems - thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.