Why is there no API key/token being used for authentication? This is like standard practice for APIs.

Instead you use the username and password of the account. I would consider this bad security. A normal user password who manages the bookkeeping should be separated from the exposure of a potential security breach on the server where they could see the source code.

If the API client code has restricted usage on some functions a breach can not access your entire e-conomic account. But since you are using the username and password, anyone with the source code access can login and do anything on the website.

To get another user called "api" for your account you need to pay extra per month?

Are the passwords in e-conomic even encrypted?

Hi Zyme,

Using regular user credentials for API authentication is actually deliberate, since it facilitates consolidated access control, as well as 'crediting' of actions (e.g. booking of invoices, which is 'credited' to a specific user account in Settings -> Log).

You are of course correct that if your integration server is compromised, your credentials will be, too - IF your server holds unencrypted source code. However, (1) There are ways of preventing that (hold only compiled, encrypted code on your server), and (2) Even with a key/token system as an alternative authentication method, having your source code compromised would still expose 'sufficient credentials' to an attacker - the fact that he'd only be able to use those credentials via the API doesn't really constitute security...

And yes, passwords are of course encrypted in our end.

Having said that... We are actually looking into alternative, API-specific authentication methods, combining customer- and integration-specific keys. Not so much because some people would like some free additional user accounts - but mainly to enhance usability for end-users when enabling and disabling integrations.


Best regards,

Yeah well...

1. In PHP you can't encode the source code reliably. Even if you encode parts of the code with an encoder they can still use "echo $password" to get the credentials.

2. If your API-klient is coded in such a way that it cannot do everything, only the things it is supposed to do. I fyou were using API-keys, an intruder cannot login to your account and mess around with other features that are not included in the API-klient, look at reports, change settings on the account etc.

If the API-klient can only SEND information, the intruder can't GET information unless he knows the e-conomic API of course and builds his own code...

Chances are more slim but right now they could just login to the account and do whatever they feel like.

3. You can credit actions to users by having each user using a unique API-key, you don't specifically need a dedicated "API user".


So if you only let us use one account, you could at least do this:

username = e-conomic username
password = unique API key

Then we don't have to beg for a second account, and we will have less issues with having someone login to the frontend and access EVERYTHING, instead of specific parts.

P.S.

Another reason for using a dedicated API-key instead of normal password is when using an integration with a partner who utilizes the API.

Right now you submit your user and password to these third party partners / apps who will have to store the information in their databases (probably without encryption or two-way encrypt) so they can access your API.

This puts a possibility of security breach in a third party provider aswell!

And who knows if they even login to your account?

The solution to just provide an API-key instead of the normal user password is really simple and effective solution to all these problems.

Bump.

Have you considered username/separate api password approach?

Hi,

We will be offering something along the lines of this at some point - but there is currently no schedule for it.


Best regards,