Jump to content

Search for passsword using passwordlist api key

Recommended Posts

$PasswordstateUrl = 'https://passwordstate/api/searchpasswords?GenericField10=ValueToSearchFor'
Invoke-Restmethod -Method GET -Uri $PasswordstateUrl -Header @{ "APIKey" = "PasswordListSpecificAPIKeyHere" }

When using the searchpasswords api with a passwordlist api key I get:

Invoke-Restmethod : [{"errors":[{"message":"No Authorization"},{"phrase":"An error has occurred trying to validate the API Key as specified in the 'System Settings' section of Passwordstate. Please check the API Key value has been specified, and is

I would have expected that I could perform a search but only get back those items that matched my search criteria within the password list that corresponds to the API key.


Is searching with a password list api key not supported?

Link to post
Share on other sites


With your API Call above, you are trying to search across all Shared Password List - because there is no PasswordListID specified. If you are not using the System Wide API Key, you need to use the search format like below:



We hope this helps.


Click Studios

Link to post
Share on other sites

Thank you, that would help a lot.


In case it is useful here is more context around the problem we are trying to solve that leads us to need this.


We need a way to programatically reference the same "logical" password from different security contexts which do not use active directory.


Using a unique password list per security context gives us an API key for the password list that restricts access to only those passwords needed by a specific application. These passwords are copy and linked into these lists so that they are logically the same password being accessed accross many difference sets of applications.


Unfortunately because the password ID changes each time it is copy and linked we cannot use the password ID as the stable unique identifier of a logical password as we don't want to have to change the code that accesses the password for each application but want to use the same code for all applications that access that same logical password with only one changing identifier of the security context (the api key).


The method we have come up with to do that is to store a unique GUID in GenericField10 and then use the searchpasswords api to pull the appropriate password.


If a given security context (say like a windows user account which we also use in some places) has permissoins to multiple lists where the passwords are we end up getting multiple results back from the api but given that they are all logically the same we select the first result and drop the rest.


If you make the change so that we don't have to specify a password list id then that would let us move forward with this work around and be able to reliably identify the same logical password and access that same logical password via the same api call only changing the API key, regardless of the various difference security contexts that might need it.


I would rather have a stable unique ID for a password that could be used with the passwords api to pull one instance of the same logical password regardless of where it is stored in the system as long as the security context I am connecting with (api key) has access to the logical password somehow.


If we could access the passwordstate API using locally created passwordstate user accounts that could then be granted password level permissions that would also help or if we could have API keys that we could grant access to passwords in arbitrary locations (like what is possible for an AD user for instance) that would also help.


Hopefully this provides more context around what we are doing and why this is needed. If there is a better way to accomplish I would be happy to learn.


If we could use windows accounts for everything that would also help alleviate this but in our context one of our growing use cases is accessing passwordstate from docker containers running linux and we have not found a way to use the windows authentication API from a linux container.


Even if we could we would rather not have to have an AD user created that could possibly be used as an attack vector for other aspects of our environment when what we really need is just a unique security context within passwordstate which if we had to use a user to get, would be better done by a passwordstate only user instead of an AD user.



Link to post
Share on other sites
  • 1 month later...
  • Create New...