Drats, you're right. I thought it'd be worse, but the ratio seems to only depend on the number of letters in your character set: 1/count(letters in alphabet).
For ascii at 95 printable chars you get 0.9894736842. Makes intuitive sense as the "weight" of each digit increases, taking away a digit matters less to the total combos.
Maybe I'll start using one Japanese Kanji to confuse would be hackers! They could spend hours trying to brute force it while wondering why they can't crack my one letter password they saw in my terminal prompt. ;)
I’ve occasionally contemplated using some non-ASCII character like • or š in a password, but have backed off for fear of needing access from a device that doesn’t support input of those characters.
When the IME inserts the character, it'll be made up of multiple bytes because of the nature of UTF-8, so it may appear as multiple asterisks regardless.
Most software, traditional sudo included, would respect the LC_CTYPE being set to an UTF-8 (or any of the older multi-byte encodings), and do proper character counting.
At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.
Having LC_CTYPE bit set to utf8 would be my worry. Would suck to not be able to logging because the LC* lang changed.
Hmmm, hopefully sudo-rs respects LC* env vars. I recall reading a few years back that some Rust Unix tools skipped that and won big on benchmarks until folks realized they weren’t handling NC localization properly.
It could also give useful priors for targeted attacks, "Their password is 5 characters, and their daughters name is also 5 characters, let's try variations of that".
Some system accessible to hackers who can see the length of the password /and/ having a single 5 char password has a security of a key under a doormat.
