@c-prompt opened this Issue on February 13th 2019

Referencing plugin-LoginLdap #176 (After updating to piwik 3.8.0 Ldap stops working), I am also seeing the error "Please enter your password to confirm this change" when a user changes a password via the API, like:

https://mysite.com/matomo/index.php?module=API&method=UsersManager.updateUser&userLogin=test_user_1&password=test_password&alias=test_user_1&format=JSON&token_auth=my_token

I have cleared the cache as recommended in #176 and do not use the LDAP plugin so I'm guessing this is a bit more complicated than just a cache problem. Matomo v3.8.0

@tsteur commented on February 13th 2019 Member

You will need to add a parameter &passwordConfirmation=password see https://github.com/matomo-org/matomo/blob/3.8.1/CHANGELOG.md#breaking-changes

@c-prompt commented on February 13th 2019

You will need to add a parameter &passwordConfirmation=password see https://github.com/matomo-org/matomo/blob/3.8.1/CHANGELOG.md#breaking-changes

Shame on me for missing that breaking change. Thanks @tsteur

@c-prompt commented on February 14th 2019

You will need to add a parameter &passwordConfirmation=password see https://github.com/matomo-org/matomo/blob/3.8.1/CHANGELOG.md#breaking-changes

@tsteur, there's a pretty large problem (at least from my perspective) with the approach taken. As https://github.com/matomo-org/matomo/blob/3.8.1/CHANGELOG.md#breaking-changes says:

When changing the email address or the password through the UsersManager.updateUser API, a new parameter passwordConfirmation needs to be sent along with the request containing the current password of the user issuing the API request.

Well, API requests often will not use the specific user's token_auth - they will use an admin's token_auth. That means the admin's password would have to be retrieved which not only adds undue risk but also seems like an unnecessary step. It's valid to ask for the user's current password as confirmation... but not the admin's.

Don't you think?

Granted, I can rework all of my app's API code and, for user password and email changes, send the user's token_auth instead of the admin's (which I don't store and, according to #11159 I can't get via the API anymore). Thus, I'm going to have to hit the piwik_user table directly. Is this the way you anticipated we'd get around the issue?

@tsteur commented on February 14th 2019 Member

Well, API requests often will not use the specific user's token_auth - they will use an admin's token_auth. That means the admin's password would have to be retrieved which not only adds undue risk but also seems like an unnecessary step. It's valid to ask for the user's current password as confirmation... but not the admin's.

I suppose we could potentially validate against the user's or the token owner's password. In general as long as it is sent via POST and through SSL it shouldn't be too much of a risk or what are you thinking of?

What's your use case? Do you have a UI where users can change the password?

There's otherwise the possibility to write a simple plugin that still lets you update the details without a password confirmation but of course it is less secure.

@c-prompt commented on February 14th 2019

Yes, in my app, a user can change his password and then the API automatically changes it in Matomo. I built a bunch of other Matomo API requests (e.g., adding new users and sites, adding/removing user access) and they all use the admin's token_auth (because individual users don't have the Matomo credentials required to make those changes).

I don't want to write code that decrypts the admin's app password just to send it in a POST (even though it's secured via SSL), especially given I already have code to send the token_auth. So my least-resistance path at this point is to just grab the users token_auth directly from the database.

@tsteur commented on February 14th 2019 Member

BTW: You want to send those requests through POST request otherwise you may have eg the token_auth from the request in web server log files

Yes, in my app, a user can change his password and then the API automatically changes it in Matomo.... and they all use the admin's token_auth

Not sure if it's a web app or hits the network at all etc. But if it hits the network, it means the users will be able to get the admin token and eg delete other users, make other changes etc. Ideally you retrieve the token_auth of a user through UsersManager.getTokenAuth($login, $pass) and then use the user's token for all requests. Anything else is not really secure.

@c-prompt commented on February 14th 2019

Ideally you retrieve the token_auth of a user through UsersManager.getTokenAuth($login, $pass) and then use the user's token for all requests.

Thanks - I can do it that way.

@hhrealestatemedia commented on February 15th 2019

What part of authorization is the token used for if you also now have to include the password? Like @c-prompt we manage the several accounts so now we have to send the admin password with the request.

@tsteur commented on February 15th 2019 Member

If you send the admin token, you very likely should change your app to send the user's token for security purposes and then also ask the user again to enter the current password before changing the password. This is common practices pretty much anywhere in the web. We are enforcing this behaviour for security purposes through the API

@grzech1983 commented on March 12th 2019

I would like also to jump in into discussion. I'm using this library:

https://github.com/matomo-org/piwik-dotnet-api

to manage Matomo users in control panel which I'm using in shared hosting environment. This module does not contain admin password at all. Only thing which is passed is API token which should be enough for managing all Matomo functions. Now when some of my customers reported that they can't change their password I've started to dig in and I've found that

public Hashtable updateUser(

method does not contain passwordConfirmation and then I've checked that his param must include admin password for using this method. Since this library does not contain any admin password param and also I'm not storing this information in user control panel database because of having already generated token API access I'm asking why why did you do this. This breaks a lot of environments IMHO.

@tsteur commented on March 12th 2019 Member

@grzech1983 I suggest you create an issue on https://github.com/matomo-org/piwik-dotnet-api to add a parameter for this. And you shouldn't send the admin password but ask the user for their current password before changing it. And also make sure to not use an admin token as this is not quite the best way and may not even be 100% secure depending on your app.

@grzech1983 commented on March 13th 2019

Users are managing their stats accesses through hosting control panel which has admin token as a administrative point for managing all stat accounts and sites.

Anyway for now I've resolved this problem by just deleting user and creating it again since it was quick workaround possible to achieve with current piwik-dotnet-api project code.

@c-prompt commented on March 19th 2019

What's your use case? Do you have a UI where users can change the password?

Just discovered another use case that's now broken: in my app, users can request new passwords when they forgot theirs. My app will generate a temporary new password that's emailed to them. However, I can't update that temporary password in Matomo because I don't have the current password. Any suggestions on how to address please?

If we can't use the API without a current password, one alternative is to follow the instructions from HOW DO I CHANGE THE SUPER USER’S PASSWORD WHEN PASSWORD RECOVERY EMAILS ARE NOT SENT? and use SQL to manually update the password column in the piwik_user table.

@tsteur commented on March 19th 2019 Member

updating the password in the SQL table would work 👍 Otherwise only chance would be to send the admin password unfortunately.

In general it sounds like it's a problem that the password reset is not exposed through an API. Maybe create an issue for this? (although we would likely not work on this right away and would hope for some community contribution I suppose)

This Issue was closed on February 13th 2019
Powered by GitHub Issue Mirror