Jump to content

Browser Extension with Shared with Reason Lists


KC_BREC
 Share

Recommended Posts

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

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

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

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

  • 2 weeks later...

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

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...