4 ms·

Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be go

Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be good for password security past experience has made me paranoid. Not all systems handle non-ASCII the same way, so when you change browsers or they upgrade their system your password might no longer work. Today Unicode is used a lot so it gets better, but it's still not universal. The worst I have seen is a system that silently removed all non-ASCII characters when entering passwords.

askmike 7y ago
That might have been an excuse in 1999, but I'm not sure it's still a valid excuse in 2019. This is why you should use utf8.
- pvorb 7y ago
  I recently debugged through a case where this was a problem with non-ASCII usernames. Through an upgrade of an underlying docker image the default system encoding changed from UTF-8 to ISO-8859-1 and nobody noticed. This even passed QA since they always create new users in their test cases and the bug only occurred if you wanted to log in as a user with a non-ASCII character that was created with an old version of the service. That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default. Long story short, encoding problems can be tricky, even in 2019.
- usr1106 7y ago
  For an implementer it is a bad excuse in 2019. For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.
cm2187 7y ago
Or if they need to connect from a foreign computer.
pvorb 7y ago
Another case where I tend to use the plain English alphabet for passwords/passphrases is with disk encryption. I have a German keyboard, but before Linux is up and running, I'm never sure whether the system assumes an English or German keyboard layout. And since I can't see which characters I type, the safe bet is to only use the plain alphabet and make the phrase a little longer.
eru 7y ago
Lots of them also ban space.

askmike 7y ago

That might have been an excuse in 1999, but I'm not sure it's still a valid excuse in 2019. This is why you should use utf8.

pvorb 7y ago
I recently debugged through a case where this was a problem with non-ASCII usernames. Through an upgrade of an underlying docker image the default system encoding changed from UTF-8 to ISO-8859-1 and nobody noticed. This even passed QA since they always create new users in their test cases and the bug only occurred if you wanted to log in as a user with a non-ASCII character that was created with an old version of the service. That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default. Long story short, encoding problems can be tricky, even in 2019.
usr1106 7y ago
For an implementer it is a bad excuse in 2019. For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.

cm2187 7y ago

Or if they need to connect from a foreign computer.

pvorb 7y ago

Another case where I tend to use the plain English alphabet for passwords/passphrases is with disk encryption. I have a German keyboard, but before Linux is up and running, I'm never sure whether the system assumes an English or German keyboard layout. And since I can't see which characters I type, the safe bet is to only use the plain alphabet and make the phrase a little longer.

eru 7y ago

Lots of them also ban space.