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