Twitter Consumer Key Regex Change

[joeleonjr]

The TwitterConsumerKey detector has outdated regex sizes and char sets. In particular, the secret needs to include - (perhaps other chars) and the key needs to have a larger range (I generated a key with 34 chars). The detector still works and detects creds generated in the past, but if you generate new consumer creds, the keys and secrets aren't always being detected.

[shahzadhaider1]

Hey @joeleonjr,

I looked into the TwitterConsumerKey detector issue you mentioned and did some testing on my end. I created several new consumer key pairs through the Twitter Developer portal and tested them against our current regex patterns. Interestingly, all the keys I generated matched our existing patterns perfectly - the consumer keys were consistently 25 characters and the secrets were 50 characters, all alphanumeric.

Regarding your comment about generating a key with 34 characters - I'm curious about how you achieved this. When I went through the standard Twitter app creation process, I didn't see any options to customize the key length or character set. All my generated keys followed the same format that our current regex expects.

Could you share more details about your key generation process? Were you using a specific API version, or perhaps a different developer portal interface? This would help me understand if there's a new format being used that our detector isn't catching.
For reference, here is the link I am using to access the Twitter/X portal:
https://developer.x.com/en/portal/projects-and-apps

And here is the portal I used to generate consumer keys:
https://developer.x.com/en/portal/projects/project_id/apps/app_id/keys

Here are our current regex patterns:

Consumer Key: \b([a-zA-Z0-9]{25})\b
Consumer Secret: \b([a-zA-Z0-9]{50})\b

Also, you mentioned that secrets should include hyphens - none of the secrets I generated contained any special characters. If you have examples of the newer format (even obfuscated ones), that would be really helpful for updating our detection logic.

Thanks for bringing this up - I want to make sure we're covering all the current formats properly.