the hashcat forum software (CMS) uses mybb. The mybb community/devs implemented the password reset mechanism with a temporary password. It's not your original password. The original password is stored in a strong hashed format and can't be seen in plain text. There are disadvantages and advantages of this temporary password.

I think that the security of URL-based reset tokens and temporary passwords are almost the same as long as the users follow the instruction and change the password (after resetting the account/password) to a secure password that only will be hashed and never be sent via mail.

I'm not sure how you came up with those 720 masks, my command from above:

will have an output of 928 masks. 720 masks is not what I get by applying the #2 filter.

The overall reduction will be tiny as I said, just a few percent !

You can get a feeling by just using maskprocessor with -1 ?l?d and a smaller/growing mask ?1?1?1... e.g.

vs

or

vs

etc

with increasing length of the password the percentage between all password candidates without -q 2 and a run with -q 2 filter will increase a little bit (8 % with length 4, 10 % reduction with length 5, etc)

The math behind it is a little bit tricky (combinatoric) because we need to consider all factors

- how many total different chars

- how long are the passwords

- what needs to be removed (length 2 of identical adjacent chars up to length 10 of identical adjacent chars)

the overall formula is just:

combinations = 36 ^ 10 - all_combinations_of_2_or_more_adjacent_chars

I think the correct forumla is something like this: https://link.springer.com/article/10.1007/BF01819761

but I'm pretty sure that it's not that much of the overall keyspace.

of course this needs to be combined with your additional filter #2 (which could have also some overlapping passwords that are filtered out, i.e. filter #2 and #3 if applied individually could remove the same password independently).

You see that the math is a little bit tricky, but overall I guess we are speaking about a few percent (10% + 10-15% I guess).

update: fixed the statement about increasing vs decreasing percentage depending on the password length

I think that the security of URL-based reset tokens and temporary passwords are almost the same as long as the users follow the instruction and change the password (after resetting the account/password) to a secure password that only will be hashed and never be sent via mail.

I'm not sure how you came up with those 720 masks, my command from above:

Code:

`./hashcat --stdout -a 3 -1 ld ?1?1?1?1?1?1?1?1?1?1 | grep -v dddddd | grep -v llllll | sed 's/\(.\)/?\1/g'`

will have an output of 928 masks. 720 masks is not what I get by applying the #2 filter.

The overall reduction will be tiny as I said, just a few percent !

You can get a feeling by just using maskprocessor with -1 ?l?d and a smaller/growing mask ?1?1?1... e.g.

Code:

`mp64 -1 ?l?d ?1?1?1?1`

vs

Code:

`mp64 -q 2 -1 ?l?d ?1?1?1?1`

or

Code:

`mp64 -1 ?l?d ?1?1?1?1?1`

vs

Code:

`mp64 -q 2 -1 ?l?d ?1?1?1?1?1`

etc

with increasing length of the password the percentage between all password candidates without -q 2 and a run with -q 2 filter will increase a little bit (8 % with length 4, 10 % reduction with length 5, etc)

The math behind it is a little bit tricky (combinatoric) because we need to consider all factors

- how many total different chars

- how long are the passwords

- what needs to be removed (length 2 of identical adjacent chars up to length 10 of identical adjacent chars)

the overall formula is just:

combinations = 36 ^ 10 - all_combinations_of_2_or_more_adjacent_chars

I think the correct forumla is something like this: https://link.springer.com/article/10.1007/BF01819761

but I'm pretty sure that it's not that much of the overall keyspace.

of course this needs to be combined with your additional filter #2 (which could have also some overlapping passwords that are filtered out, i.e. filter #2 and #3 if applied individually could remove the same password independently).

You see that the math is a little bit tricky, but overall I guess we are speaking about a few percent (10% + 10-15% I guess).

update: fixed the statement about increasing vs decreasing percentage depending on the password length