Increase length of API tokens

[scolapasta]

It was suggested that we increase the length of the API tokens to something longer, asa an example the same length of characters of the github tokens.

This should be straightforward to do, but we will need to decide if we invalidate all shorter tokens when we release this.

[djbrooke]

@scolapasta I created a token in Github and it was 40 characters vs. 36 in demo.dataverse.org. Should we just increase by this small amount or should we add more?

[scolapasta]

I mentioned github because that was the suggestion we got, but I also thought the suggestion was twice as long? Clearly something I'm remembering is wrong. :/

[landreev]

Can I ask why this is needed - what were the reasons given?

[djbrooke]

@scolapasta you're right, I see it in the notes. Heh.

[djbrooke]

• Let's add 6 characters because we are overachievers.
• Let's not force any expiration for now, but we will plan to regenerate tokens when sensitive data support starts
• Add a release note for installations that want to wipe out all the tokens (and they can deal with the messaging to their community)
• Note issue Add API endpoints to help manage API tokens #6266

[qqmyers]

FWIW: https://neilmadden.blog/2018/08/30/moving-away-from-uuids/ points out that UUIDs (looks like what we use) only have 122 bits of randomness and RFC 6749 (for OAuth2 tokens) suggests at most a 1 in 2128 chance for a guess to succeed (and 2160 is better). The rest of that blog and the discussion at OWASP (https://owasp.org/www-community/vulnerabilities/Insufficient_Session-ID_Length) makes it pretty clear that even with the length we have brute force is not a practical attack (if you ignore the blog's example of the world's bitcoin hashers trying to find one of your 2**46 tokens you've minted for every IOT device on the planet example). (Some of the timing attack possibilities might enable a more practical attack even with reasonable hit rate and number of token arguments.)

Never-the-less, if we're making a change, going to 160 bits of randomness (e.g. the 20 bytes suggested in the blog, or 40 hex (0-f) chars) would perhaps be a good/very defensible choice. We really only have 32 chars now since 4 of the 36 are hyphens and of the 32, 1.5 are not random (they code the version/variant of the UUID), so adding 6 chars to the end of our UUID as the guess above only gets us to 36.5 random hex chars).

[cmbz]

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.