I'm assuming "dict size" is the count of possible characters (see how it's 10 for the previous example). For the second example a dict size of 18 presumes the attacker is generating passwords with only those 18 characters that are used. It's true that the first example would be about 1.4 orders of magnitude slower to crack than the second. In the only digits case a cracker would try only digits because passwords with only digits are somewhat common (not usually that long though) and quick to check to fairly large length. But in the second example why would someone brute-forcing a password only try those exact characters?
Now I want to check my passwords list to see how many fit this profile of only having those 18 characters. Then see what character sets are most common overall (I already have a script to calculate the most common masks are (using the oclhashcat definition of a character mask)), but I never thought sets of individual characters would be that useful.
Making sure you have unpredictable upper and lower case letters, numbers and symbols with a not unreasonable length of 14 would force an 8 GTX 1080 rig (about $5200 US for just the video cards) to take 386 thousand years to crack on average assuming MD5 for the hash function.
That argument baffled me as well. Using the 'dictionary size' defined by the distinct set of characters as an input for the entropy calculation seems absurd, unless the attacker has a way to know the dictionary, for instance because they know a login can be made using a numeric keypad alone.
Also, with that definition, a password 'abcde' would have much higher "entropy" than 'aabab', meaning that this measure penalizes actual randomness, where repetition and char-reuse are very likely.
I'm assuming "dict size" is the count of possible characters (see how it's 10 for the previous example). For the second example a dict size of 18 presumes the attacker is generating passwords with only those 18 characters that are used. It's true that the first example would be about 1.4 orders of magnitude slower to crack than the second. In the only digits case a cracker would try only digits because passwords with only digits are somewhat common (not usually that long though) and quick to check to fairly large length. But in the second example why would someone brute-forcing a password only try those exact characters?
Now I want to check my passwords list to see how many fit this profile of only having those 18 characters. Then see what character sets are most common overall (I already have a script to calculate the most common masks are (using the oclhashcat definition of a character mask)), but I never thought sets of individual characters would be that useful.
Making sure you have unpredictable upper and lower case letters, numbers and symbols with a not unreasonable length of 14 would force an 8 GTX 1080 rig (about $5200 US for just the video cards) to take 386 thousand years to crack on average assuming MD5 for the hash function.