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

[DISCUSSION] Should the REST API using App Pass auth be able to create new App Passes? #4

Closed
georgestephanis opened this Issue Jan 15, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@georgestephanis
Owner

georgestephanis commented Jan 15, 2016

Should the REST API using Application Password auth be able to create new Application Passwords?

I'm torn, because if so, applications could create more routes in, but at the same point, what's to prevent them from just sharing the existing application password or oAuth tokens and having the same problem?

@Ipstenu

This comment has been minimized.

Contributor

Ipstenu commented Jan 19, 2016

If they share the password, it's easier to revoke one password.

If RestAPI can add passwords, then we should be able to know who made the password so we can say "Aha, this app password is being abused by the rest API to do XYZ..." and track down who's the numbnut.

I'd lean towards NOT letting them make new passwords with the same idea as why we don't let just anyone make a bunch more accounts. It's easier to control someone taking advantage of an exploit if you limit their vectors.

@kadamwhite

This comment has been minimized.

kadamwhite commented Feb 5, 2016

I'd lean towards NOT letting them make new passwords with the same idea as why we don't let just anyone make a bunch more accounts. It's easier to control someone taking advantage of an exploit if you limit their vectors.

Concur.

@JeffMatson

This comment has been minimized.

Collaborator

JeffMatson commented Feb 6, 2016

Agreed. We're dramatically changing the security and purpose of the one-time passwords if they're able to make additional changes.

@kjbenk

This comment has been minimized.

Contributor

kjbenk commented Feb 10, 2016

What do you think about making two types of passwords? Upon creating a password the user can chose to either create a:

  1. Generic Password, that does NOT have the ability to create new passwords
  2. Super Password, that does have the ability to create new passwords

We can make this a checkbox and this way the user can decide whether each password is consider generic or super. Let me know your thoughts @georgestephanis.

@georgestephanis

This comment has been minimized.

Owner

georgestephanis commented Feb 10, 2016

Honestly, I think we're overthinking this at the moment.

This is an authentication system -- I'm not sure if it's our place to restrict what said authentication can be used for.

If someone swipes your real password, they can log in and change your real password, change your email, whatever.

If someone swipes an application password, they can use it for whatever available endpoints there are.

To say they can't make new application passwords with it feels silly -- as they'll likely be able to use it to do everything else on their user profile, from changing their email address to potentially updating their normal password. Because that's what an API does.

The only real way forward if this winds up being an intentional (and in my mind at the moment, unwise) design decision would be to filter out what branches of endpoints can and cannot be used.

For example, with the current REST API's "four data structures/endpoints" pattern, a given application password may grant access to the Post, Taxonomy, Comments endpoints, but disallow any User endpoints. Whether based on a whitelist (only allowing named ones) or blacklist (only disallowing named ones) would be up for discussion, naturally, but it's the only rational way I see of moving forward on this -- if it must forward at all.

We must also weigh that against the additional user complexity of having to explain those restrictions to users -- and the support burden it would likely generate to the forums squad -- versus just including a disclaimer that "Application Passwords give access to all REST API endpoints. Don't give it to an application or person that you wouldn't trust with your full login."

@kjbenk

This comment has been minimized.

Contributor

kjbenk commented Feb 10, 2016

I agree with with your argument. I think adding:

Application Passwords give access to all REST API endpoints. Don't give it to an application or person that you wouldn't trust with your full login.

to the Application Password section somewhere would fix this issue.

@JeffMatson

This comment has been minimized.

Collaborator

JeffMatson commented Feb 10, 2016

I'm going to disagree with you. The point of single use separate passwords is to better regulate access. Allowing it to make changes to passwords and such defeats the purpose, in my opinion.

A better solution to this would be to configure access on password creation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment