non-english unicode characters result in -Infinity% complexity

[munkyboy]

steps to reproduce:

• enter in Kanji or Arabic characters

expected results: possibly rely on just length to calculate complexity?

actual results: complexity reported as -Infinity%

[danpalmer]

I'm not sure about the best way to solve this. I am actually unable to replicate it when typing, it seems that Mac OS does not respect Pinyin for secure fields and instead just uses normal text entry. The only way I can input special characters outside what's available on my keyboard is to use the Special Characters pallet.

How are you entering the characters? Is this on a non-latin keyboard layout?

I am not sure how to implement the check. Right now it has the character sets hard coded, I was thinking about using the ASCII or Unicode character and comparing bounds, it might be more difficult to include all punctuation, I'm not sure it's all in a contiguous range, but also, anything above the normal ASCII range can be counted as a special character and an increased complexity be calculated.

Another problem is then defining the correct increase in complexity. The algorithm I have used will scale appropriately and differently for each additional character set. For example, adding a number means that the minimum set needed to brute-force the password will be 10 characters larger and therefore 10^n more operations. If we treat 'the rest' of the Unicode characters as a single set (~65000 if I remember correctly) then the complexity will be hugely affected.

If you put yourself in the shoes of an attacker, ask yourself "what character set am I going to brute-force with". To choose to attack with just lower case characters, or lower + numbers, would be a valid consideration to save time. You won't get all passwords, but you will get a large number (unfortunately). Would an attacker ever add other smaller sections of Unicode such as Kanji or Arabic, or Chinese? Now, would you ever choose to include the full unicode character set? Probably not.

Basically it comes down to this:

• Should I change the plugin to calculate character sets based on Unicode numbers instead (probably yes)
• What should the 'cost' be in the algorithm for including the extra characters, can 'the rest' of the characters be broken down into smaller sets that would likely be used separately.

[danpalmer]

I added unicode support in da1c854d3b4b64bd05bd01636521778c2db04be5 - let me know if this works as you would expect.

[munkyboy]

nice. looks good