Jump to content

Using Browser Extension - Auditing Concerns


Recommended Posts



I tried to see if this issue has already been brought up but did not find anything.


It has been brought to my attention, the following scenario:

A user browses a website, lets say "https://portal.office.com" where they have a password entry saved in their private password list. We also have a high number of shared passwords that have the same URL. When the user browses "https://portal.office.com" the auditing log shows that the user "retrieved password" for every password we have in the database using that URL.


I feel that this process should be revised (assuming it has not been yet as we have yet to update to the latest version). There shouldn't be an audit entry stating that the password was retrieved unless it was actually pulled and used.

Maybe pull a list of titles/usernames and audit that but not the actual password unless it is intended to be used by the end user. This fills up the auditing log and could cause for some confusion when a user is showing tons of password pulls when they did not intentionally do so.


Has anyone else run into this?


Thank you.

Link to comment
Share on other sites



Yes, we are aware of this issue and have fixed it for the next rounds of releases for broswer extensions. We did not want to release so late in the year, as these new extensions when they automatically update in your browser, will force you to also upgrade Passwordstate if you want to continue using the extensions - there is a dependency change in the API needed here.


So we will release these updates at the start of next year.


Click Studios

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
  • Create New...