Feature Request: Add Authentication to API calls

[l.sausen]

Hello everyone,

 

first of all I want to stress that I really like Passwordstate a lot. Great product which is easy to use and provides a ton of features!

Nevertheless I think the current Web API implementation is quite problematic.

Right now, every person with knowledge of the Web API Key of a password list can access the stored information in the respective list.
In my understanding, this policy is a serious security vulnerability since such easy accessibility thwarts the whole concept of role-based permission handling.

 

For the following two reasons I would urge an additional authentication via Username and Password in the API Call:

 

1. API usage becomes highly inconvenient in situations where a specific API Key is utilized by multiple users.  Every change in the group of authorized persons must subsequently result in the generation of new API key to ensure the application of the authorization model. Especially when people leave the company one cannot risk to expose new or changed passwords / hosts via the API. However, this has to be done manually for every password list. Therefore, the whole process of enforcing permissions is highly prone to errors since one has to track down every affected list.  
2. API-Keys cannot be stored in any code that might be visible to a 3rd party. Since knowledge of the API key equals access to the password list such non private code offers access to passwords to  completely unauthorized individuals.

 

Having some (optional) form of authentication (preferably via Oauth) in the API call would help a lot to ensure that authorization models can’t be breached via an “API Backdoor”.

 

See also: https://nordicapis.com/why-api-keys-are-not-enough/

 

Kind regards,

Lukas

 

 

 

 

[support]

Hi Lucas,

 

Thanks for your request. We believe having some sort of additional Auth for the API would cause issues with various scripting environments, which is why we have not considered it to date. We're also considering adding a "per user" API Key as well in a future build.

Have you considered the use of our Windows Integrated API - this does not require API Keys at all, and gives you the same level of access as logging into the UI.

 

You also have complete control over who is allowed to use either API, which can be found in the Administration area. So if you have some concerns here, you can restrict access to a certain degree. You can also restrict which IP Addresses can be used to make API Calls from - this can be found on the screen Administration -> System Settings -> Allowed IP Ranges.

Regards

Click Studios

[l.sausen]

I tried to check out the Win API documentation. However, I experience the same problems as described in this post.

 

In addition, we only have the forms based authentication for passwordstate, therefore the Win API is of little use to us, right? 

[support]

Hello,

 

Yes, if you are not using AD Integrated authentication, then unfortunately you cannot use this version of the API. If you're interested in converting to this, let me know and I can email you some instructions.

Regards

Click Studios

[Sarge]

On 4/25/2018 at 1:51 AM, l.sausen said:

Right now, every person with knowledge of the Web API Key of a password list can access the stored information in the respective list.

I share this concern, but at the same time the Passwordlist can have ACLs configured. 
However if there's a feature request to add authentication to the REST API plus API key and ACL usage then I'd have to +1 it; although per-user API keys would probably also suffice.

[sysadmin-z]

I would like to +1 per user API keys

[support]

Thanks

[Alexey P]

Was per user api key implemented?

 

Per password list API keys makes to almost impossible to deal with multiple password lists unless keys are synchronized. But even then, permissioning is very limited, its all or nothing. kerberos authentication is not an option for non windows tool machines.

[support]

Hi Alexey,

 

You can use our Windows Integrated API from Linux - please see this post - https://www.clickstudios.com.au/community/index.php?/topic/2387-can-winapi-be-used-via-a-linux-shell-script/

Regards

Click Studios

[Alexey P]

Using `curl --ntlm` is not an option, this is specific to Linux, we are writing cross platform  powershell modules as we have to run tools from windows/mac systems.
 

I will have to investigate if `Invoke-WebRequest` or `Invoke-RestMethod` has similar capabilities to `curl --ntlm` headers negotiation strategy.

[support]

Hi Alexey,

 

In that for post I linked to, another customer said they are using the syntax below, and it's working for them. Is this not working for you, possibly because your version of curl does no support this switch?

 

curl  --ntlm  -u "user:pass" "https://passwordstate_url/winapi/passwords/XX"

Regards

Click Studios

[Alexey P]

Hi, no its not working because Curl not available on windows without installing it from external source, and running something via external executable in powershell is a pain (powershell poorly handles arguments to external executables: https://github.com/PowerShell/PowerShell/issues/1995 this never ending thread).

We are building all automation in powershell, which then we can utilize on windows/linux/macos. I will have to figure out how to achieve this using `Invoke-WebRequest` or `Invoke-RestMethod` powershell calls.