Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for app specific tokens #6559

Closed
2 tasks
tsteur opened this issue Oct 30, 2014 · 6 comments · Fixed by #15410
Closed
2 tasks

Add support for app specific tokens #6559

tsteur opened this issue Oct 30, 2014 · 6 comments · Fixed by #15410
Assignees
Labels
c: Security For issues that make Matomo more secure. Please report issues through HackerOne and not in Github. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@tsteur
Copy link
Member

tsteur commented Oct 30, 2014

It would be great if a user could create app specific passwords and revoke them if needed.

For instance you might want to create a new app specific password for each device when using the mobile app. If you ever lose a device (phone) you can simply revoke the password that you have used for this device but all other passwords would be still valid.

You do not want to create a new user for the mobile app with a different password as you would have to sync/change the dashboards and ViewDataTable params for each user. Once we implement features like "Continuity" one would still benefit of those features. With "Continuity" I mean when opening the mobile app it could open the same website and report that you have accessed last on the desktop although different passwords are used etc. This would not be possible if someone had to create multiple users for each device.

You might also want to generate app specific passwords for different servers that talk to the Piwik HTTP API etc.

It will be also useful if we ever generate 2-factor authentication.

App specific passwords would consist of an App name (eg PiwikMobileApp, or PythonClientWhatever), a device (eg PhoneXYZ or ServerXYZ) and a generated password. This password would be ideally quite long, eg 16 characters. Before someone can generate a new specific app password we should ask him for his actual password and only generate / or only let him manage his app passwords if the actual password is correct.

Some systems that do support app specific passwords would not let you log in into the browser version (meaning regular Piwik login) with an app specific password but we would probably still do?

  • Store tokens / passwords hashed
  • Do no longer show them anywhere in the UI
@tsteur tsteur added the c: Security For issues that make Matomo more secure. Please report issues through HackerOne and not in Github. label Oct 30, 2014
@mattab
Copy link
Member

mattab commented Oct 31, 2014

We discussed this idea while investigating: matomo-org/matomo-mobile-2#5275 - see also two factor auth which would benefit #2846

@mattab
Copy link
Member

mattab commented Mar 27, 2017

Currently users have some issues with the fact that the token_auth is not found in API responses (see #11159 ). We know that one could create a plugin that would add back into API responses the token_auth. But I'm wondering if we could provide another (more secure) solution, with this App-specific passwords discussed here.

Use case

  • As a Super User, I want to give my customers (read only) access to their reports via a report Embed iframe. For this as a Super User I want to write a script which creates a "Read-only" access to reports for a website, for which I need a API token_auth with read-only access.

Would this use case be met with App Specific passwords?

Could App specific passwords also help with this use case above? @sgiehl maybe you can confirm whether App-specific password would help here and if so, how would it be scripted by calling the API?

@sgiehl
Copy link
Member

sgiehl commented Mar 27, 2017

If we implement the app specific passwords as kind of additional token_auths for a user the api would be called as usual, but as token_auth a app specific password would be given. So it would match your use case

@mattab
Copy link
Member

mattab commented Mar 27, 2017

  • you mean the &token_auth= will also accept app-specific passwords as value?
  • to meet my use case above, it sounds like we would also need the ability to customise the permission of an app-specific password, ie. give my app-specific password only "View" permission to website X and "Admin" permission to website Y. wouldn''t that too complex for this App Specific password feature?

@tsteur
Copy link
Member Author

tsteur commented Mar 27, 2017

App specific passwords won't "fix" this problem. Eventually, app specific passwords will replace token_auth from user table. For each different app you want to access the API, you create an app specific password. This password or token will be only shown once and afterwards securely stored and surely we won't be able to return it in clear text in API or UI for security.

As a Super User, I want to give my customers (read only) access to their reports via a report Embed iframe. For this as a Super User I want to write a script which creates a "Read-only" access to reports for a website, for which I need a API token_auth with read-only access.

While it will be for sure useful to assign read-only / read-write (like view / admin) access to app specific passwords, this won't fix the use case you are describing. You are still giving away the token to view all data etc. They could already now create a user with view access, and use the token to embed the iframe. And you can get the token from the API if you have the users original password.

@tsteur
Copy link
Member Author

tsteur commented Jan 8, 2020

It's already clear that when we remove the token_auth, we will only store secure app specific passwords see #9457 and they will be only shown after creation #13710

@tsteur tsteur self-assigned this Jan 9, 2020
tsteur added a commit that referenced this issue Jan 10, 2020
Fix matomo-org/matomo-mobile-2#5404

Not writing a test for it as I'm removing this API method as part of #6559 anyway.
tsteur added a commit that referenced this issue Jan 12, 2020
* Support email address in getTokenAuth

Fix matomo-org/matomo-mobile-2#5404

Not writing a test for it as I'm removing this API method as part of #6559 anyway.

* Update API.php
@mattab mattab added the Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. label Jan 30, 2020
jonasgrilleres pushed a commit to 1024pix/pix-analytics that referenced this issue Sep 22, 2020
* Support email address in getTokenAuth

Fix matomo-org/matomo-mobile-2#5404

Not writing a test for it as I'm removing this API method as part of matomo-org#6559 anyway.

* Update API.php
jbuget pushed a commit to 1024pix/pix-analytics that referenced this issue Sep 26, 2020
* Support email address in getTokenAuth

Fix matomo-org/matomo-mobile-2#5404

Not writing a test for it as I'm removing this API method as part of matomo-org#6559 anyway.

* Update API.php
@tsteur tsteur changed the title Add support for app specific passwords Add support for app specific tokens Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Security For issues that make Matomo more secure. Please report issues through HackerOne and not in Github. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants