Avoid generating backup codes composed only of letters or only of numbers

[Ahosall]

Description

Currently, the script is generating backup codes that consist only of numbers or only of letters. However, according to Discord’s backup code rules, valid codes are composed of a mix of letters and numbers, not exclusively letters or numbers.

Describe the solution you'd like

I suggest adding a validation rule, if possible, during backup code generation to filter out codes that contain only numbers or only letters. This could slightly increase the chances of success while avoiding attempts with clearly invalid codes.

Possible combinations using only letters: 208,827,064,576
Possible combinations using only numbers: 100,000,000

This would reduce the total search space from 2,821,109,907,456 to 2,612,382,842,880, representing an approximate 7.39% reduction.

Describe alternatives you've considered

No response

Any other context/information?

I'll use this space to ask a question. Were you able to recover your account? 😆 How long did it take to get the OTP or backup code right?

[Derpitron]

Hi, this is the line of code that provides the backup code pattern:

Discord-OTP-Forcer/src/lib/types.py

Line 40 in b261f26

pattern: str = r"[a-z0-9]{8}"

I didn't know it generated only-numbers or only-letters codes, in my testing and from other people it seemed to generate mixed-letter-and-number backup codes just fine?

Also, could you prove that only-numbers or only-letters never/rarely occur as backup codes? I know they're rare to actually see but afaik it's entirely possible they occur, so it makes sense to capture them in that regex pattern.

[Ahosall]

Hi!

I didn't know it generated only-numbers or only-letters codes, in my testing and from other people it seemed to generate mixed-letter-and-number backup codes just fine?

I did some filtering by checking the code I had already used in my own attempts before refining my version. Here’s an image showing that.

Also, could you prove that only-numbers or only-letters never/rarely occur as backup codes? I know they're rare to actually see but afaik it's entirely possible they occur, so it makes sense to capture them in that regex pattern.

To verify whether backup codes are generated with only numbers or only letters, I ran multiple tests by generating and regenerating backup codes on two different Discord accounts I own. Based on these tests, the probability of getting a code with only numbers or only letters is significantly lower than getting a mixed alphanumeric code.

In my local version, I added a restriction to avoid generating codes that contain only numbers or only letters. I’m currently at attempt 3500 😆

This conclusion is based on empirical testing rather than an official guarantee, but in practice, mixed alphanumeric codes appear to be the standard output.

[Derpitron]

Only now I understood what your point was. My bad
I'm still not sure if it's good to keep mixed-only as the standard. If you like you can use a custom regex pattern that enforces mixed-only in the program config, using lookback/lookahead

If you do decide to do more testing to see whether Discord really generates mixed-only codes, we could prolly change it

[Derpitron]

Also I see you made a fork which apparently fixes some of the HTML button element order. If that works, could you make a PR here?

[Ahosall]

If you do decide to do more testing to see whether Discord really generates mixed-only codes, we could prolly change it

Ok, I will run a few more tests, and once I have results, I’ll report back here.

Also I see you made a fork which apparently fixes some of the HTML button element order. If that works, could you make a PR here?

Regarding my proposed change to the button order, I’m still evaluating it. So far, the account I’m trying to recover only requests backup codes and does not present the option to authenticate using OTP.

I also plan to schedule some time to test additional ways of submitting codes, such as interacting directly with the endpoint. I’ll share any updates as soon as I have new findings.

Thank you for your attention!