@tsteur opened this issue on October 30th 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
@mattab commented on October 31st 2014

We discussed this idea while investigating: https://github.com/piwik/piwik-mobile-2/issues/5275 - see also two factor auth which would benefit #2846

@mattab commented on March 27th 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 commented on March 27th 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 commented on March 27th 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 commented on March 27th 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.

Powered by GitHub Issue Mirror