Mastodon: OAuth access tokens - never removed, never expire

[happycoloredbanana]

There are several (potential) issues with the tokens:

1. Access tokens are never removed from the database (table oauth_access_tokens). This is how it's done in Doorkeeper (doorkeeper-gem/doorkeeper#536). The table keeps growing indefinitely.

2. Every time Mastodon's web GUI is loaded, a new token is issued. Concern: will it be possible to fill the oauth_access_tokens table up by simply refreshing the Mastodon page repeatedly? Can it be used as a DOS attack?

3. Access tokens never expire, and each user ends up with a bunch of them (see the above). Probably, can be bad security-wise.

I'm not a security expert, just asking.

---

• [ x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[tobypinder]

Presumably matching for existing valid tokens using first_or_initialize/first_or_create would help with this. I haven't seen the masto implementation but might have fixed something similar in different apps using Doorkeeper.

[sungo]

In terms of token expiry, the culprit is here: https://github.com/tootsuite/mastodon/blob/master/config/initializers/doorkeeper.rb#L26 where the initializer sets access tokens to never expire.

A better config here is to set access_tokens_expires_in to some not-nil value and then set use_refresh_token (https://github.com/tootsuite/mastodon/blob/master/config/initializers/doorkeeper.rb#L42)

That'll allow tokens to expire but also allow apps to refresh their tokens using the regular oauth flow without needing the user to login again.

[sungo]

Given that the commit doesn't resolve the non-expiring oauth token issue, should I take that to mean that Mastodon has no interest right now in oauth tokens that expire and can be refreshed?

[kaniini]

hey @Gargron could you elaborate on whether Mastodon considers the lack of expiring tokens to be a security issue? do you know of any apps which explicitly depend on the lack of expiring tokens?

[Gargron]

All apps depend on that. All tokens can be revoked by the app that has them, and by the user from the "authorized applications" page. Infinitely growing table of apps is a concern, but a small one, given how tiny that data is compared to everything else. A suggestion I have voiced previously was to discard apps with no actively used tokens within the last year.

[kaniini]

What is your opinion on pruning unused tokens automatically?

[Gargron]

For end-user tokens, I think that is unnecessary. They have the page with all tokens that they can revoke if they needed to. It might be disruptive to remove them without the user's knowledge.

[lanodan]

Yes, you have a page but that list can grow to be very big and be unmanageable rather quickly, specially as you aren’t really expected to check it regularly if you’re not using the web frontend. Having expiration can help a lot there.
Also token refreshing is part of OAuth2: https://tools.ietf.org/html/rfc6749#section-6

[feld]

Token refreshing is a critical part of the security afforded by tokens in OAuth2. Allowing expired tokens to work is simply security negligence.

edit: the current situation treats tokens as "per-app-passwords" instead of what the tokens are meant for

[Laurelai]

All apps depend on that. All tokens can be revoked by the app that has them, and by the user from the "authorized applications" page. Infinitely growing table of apps is a concern, but a small one, given how tiny that data is compared to everything else. A suggestion I have voiced previously was to discard apps with no actively used tokens within the last year.

Isnt this what short lived tokens that use long lived refresh tokens are for though? Seems like the ideal solution in this case.

[kaniini]

I've spoken with a few app developers so far and all seem willing to add token refreshing support if they are lacking it already. Fedilab, for example, already supports refreshing tokens. If app developers commit to adding token refreshing support, it would be nice for Mastodon to resolve this security hole.

[Gargron]

Enabling refresh tokens should be close to a one-line change. However, Twitter doesn't use refresh tokens, which was my reason for doing the same when first setting up OAuth in Mastodon. If it's not a security hole for them, it shouldn't be one for Mastodon either.

[kaniini]

Twitter, presumably, does prune access tokens which haven't been used in a while though, which is the suggested alternative to using refresh tokens.

[feld]

Twitter also has the worst 2FA implementation available (SMS) and won't budge on it, and has a history of security gaffes like old backups having plaintext passwords. [1]

I wouldn't use them as a role model for security.

[1] https://www.theverge.com/2018/5/3/17316684/twitter-password-bug-security-flaw-exposed-change-now

edit: oh that wasn't backups, it was logs; I'm thinking of someone else, but the point remains

[Gargron]

Twitter, presumably, does prune access tokens which haven't been used in a while though, which is the suggested alternative to using refresh tokens.

Can you link to any material where this process is mentioned?

Also, pruning apps (together with their access tokens), that have not been used by anyone in over a year, is the first thing I suggested

[kaniini]

Can you link to any material where this process is mentioned?

https://tools.ietf.org/html/rfc6819#section-5.1.5.3
https://tools.ietf.org/html/rfc6819#section-5.1.5.4
https://tools.ietf.org/html/rfc6819#section-5.2.1.1

Also, pruning apps (together with their access tokens), that have not been used by anyone in over a year, is the first thing I suggested

If an access token is not used in a month, it should just be expired. (In fact, I argue that a month of idle time is extremely excessive in and of itself.)

But, optimally, Mastodon should just require using the refresh_token. That would be the best solution, and one I am already talking with app developers about implementing, as we would like to solve this in the best possible way in Pleroma.

[Gargron]

Twitter, presumably, does prune access tokens which haven't been used in a while though

I meant that one

[nightpool]

Twitter definitely doesn't expire inactive tokens, I don't know where you
got the idea that they did. I have authorized applications in my twitter
list I haven't used since 2011.

On Thu, Mar 21, 2019, 9:53 PM William Pitcock [e-mail]
wrote:

Can you link to any material where this process is mentioned?

https://tools.ietf.org/html/rfc6819#section-5.1.5.3
https://tools.ietf.org/html/rfc6819#section-5.1.5.4
https://tools.ietf.org/html/rfc6819#section-5.2.1.1

Also, pruning apps (together with their access tokens), that have not been
used by anyone in over a year, is the first thing I suggested

If an access token is not used in a month, it should just be expired.

But, optimally, Mastodon should just require using the refresh_token.
That would be the best solution, and one I am already talking with app
developers about implementing, as we would like to solve this in the best
possible way in Pleroma.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/1681#issuecomment-475466392,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV0fgfKBSrz3r2ZWrzuRf70bTEr8Hks5vZDeOgaJpZM4M8hKd
.

[trwnh]

Hmm. I would personally put my definition of idle at 3 or 6 months rather than just 1 month. But I can see that this might be different for each person. It might make sense to make it a configurable security feature, and by default set it to enabled / 90 days? Or whatever arbitrary threshold makes the most sense for the most people.

It might also be nice to have some manual additions like a button on the "authorized apps" page to force-expire all tokens not used since a certain threshold, in addition to an auto-cleaner. The annoying part is having to click "revoke" for each app, and also the list does not seem to be sorted/sortable by any criteria like date or scopes.

Personally I would either set auto-clean at 90+ days because I have a lot of devices that I use infrequently, and I don't want to worry about tokens expiring just because I waited one day longer than whatever arbitrary limit... or I would disable that and periodically clean up old apps myself, if there were easier ways to sort through and do multiple actions at the same time. That's one concession to security that I'd personally make, since I sometimes like looking through the list of old apps to remember apps that I'd forgotten even existed, as nightpool mentions.

[kaniini]

Twitter definitely doesn't expire inactive tokens, I don't know where you got the idea that they did. I have authorized applications in my twitter list I haven't used since 2011.

It was based on the assumption that Twitter somehow mitigates their bad security praxis by doing something to expire the tokens in the future, because the RFC dedicated to OAuth security discussion strongly recommends doing so.

But even if Twitter has broken security, that doesn't mean we shouldn't aspire to do better. Please let us work to do better.

[stom79]

My main concern with tokens not expiring is that apps retrieve the client id and secret dynamically unlike Twitter. So let's say that I install an application then uninstall it, a new client id and secret will be created (because previous client id and secret can't be reused) and so, a new token is also created. So for a same app, users can have a lot of not revoked token allowing read/write/follow.
So, especially due to this problem with client ids, I think that tokens should expire. For Peertube, I need to renew tokens every 24h, but in fact, when the app receives an error 401, it uses the refresh token for generating a new one.
I also use a bot and if the token is expired, it's not a problem to renew it. Maybe a first step would be to make like Pleroma allowing both methods to let the time for devs to change their code and then apply it with a clear ETA?