Just to play devil’s advocate here, what could a malicious actor knowing the token_auth of a Piwik user possibly do with it?
I take that viewing of widgets and the dashboard is possible, as token_auth is used to show those in an iframe in an external site.
But would, e.g., any of the following be possible?
[ul]
[li] Modifying the user’s dashboard (adding/removing widgets)
[/li][li] Change of the user’s settings (including password, e-mail address, etc.)
[/li][li] If the user is a super user - changes to Piwik administration, such as adding/removing users, changing users’ passwords, adding/removing sites, etc.
[/li][/ul]
I’m assuming that “enable_framed_pages” and “enable_framed_settings” (see When included in an IFrame, Piwik reports do not load. How do I allow Piwik reports to load from within an iframe? - Analytics Platform - Matomo) are kept at their default values. Although I don’t know if they have only a frame-busting effect or actually restrict what can be accessed with a known token_auth.
The background for the question is work on a plugin for password encryption in Piwik - see 301 Moved Permanently. The token_auth will not be encrypted and could still be acquired logging Piwik communication.
I already have another plugin ready, to also encrypt passwords handled by the UsersManager plugin, but it would need allowing the core UsersManager plugin to be deactivated, before it can be published - see Making UsersManager extendable by Joey3000 · Pull Request #8781 · matomo-org/piwik · GitHub. But due to the token_auth still available in clear text that would still not be enough.
Coming up with a solution to encrypt the token_auth in a plugin seems like too much work. (It’s sent both ways - to the browser and the server - and seems to be consumed by uncountable Piwik modules, which would require overwriting them all with plugins which is probably not even possible for some of them without large platform changes. In short - it looks like a no-go.)
What I could try to implement in the above plugin is to request the user to provide their current password on a password change. So that with token_auth compromised, users at least could not be locked out of Piwik by changing their password. Although other configuration changes would still be possible. That solution could work at least for non-admin users. (With a super-user token_auth on the other hand, all bets are off if the plugin can be disabled.)
The above is just a status update, no need to respond to it.
