i18n - Internationalization Password Complexity Rules

Question

I'm currently working on the internationalization of a product and an issue has come up. The issue revolves around password complexity requirements for countries with non-Latin languages and complex character sets.

The application uses aspnet membership for user and password management, although this might be a whole other issue. Currently our application has settings and code in place to accommodate A-Z, 0-9 and special characters that make up passwords, but these will more than likely require extension to cope with other cultures.

I've been searching for guidance and best practice on this and so far not had much joy. The last post on this SO question touches on the issue but doesn't really provide any guidance.

Answer 1

Depends on what you want to enforce. Dictionary checks and pattern recognition should work in any encoding and language. If you want to enforce the popular but arbitrary rules "mix of uppercase, lowercase and numerics", then, yes, you probably need to find A) a library or API that can determine case and numerics for any language or B) create a stupidly large database to map that information yourself.

That kind of complexity rules is a hack, though. Stupid people WILL create stupid passwords, no matter what kind of complexity rules you arbitrarily enforce. Best practices for password security is making sure the user has to pick a password that isn't quite as guessable as it could be, so dictionary checks (don't forget to add all words on the password creation page and all words related to password entry, the application or its environment, plus all available user-specific info, e.g. birthdate and maiden name) and pattern matching (abc123) should do.

I've actually seen a lot of cases where "abc123.-" or something similar were used as root passwords because nobody could be arsed coming up with a real password that would meet the complexity criteria.

Answer 2

[NOT QUITE RELATED]

Making a strong password really is easy:

1. Take the first line of your favourite song
2. extract the initials of the words in this line
3. randomly adjust their case
4. throw in random spl chars like *, ), ' etc at seemingly random positions
5. Voila! Its ready!!

[read somewhere on the internet]

jrh.

Answer 3

Much depends on how secure the access needs to be. For high security a password approach isn't really practical, and some kind of biometric (fingerprint?) or two-factor (SKey?) approach may be better, especially if combined with a numeric PIN.

This is because it's not really practical to perform dictionary or complexity analysis on non-Western language passwords. Specifically:

• Many languages do not distinguish between upper-case and lower-case
• Some languages encode characters in two, three or four bytes
• There is no reason to introduce numeric or punctuation characters in passwords for cultures with a large number of ideograms (such as Simplified Chinese)
• Maintaining dictionaries for a large number of languages can be impractical

For simple Web sites it may be advisable to perform stronger checks on the password if you are delivering a non-Western language version of your site to the browser.

Answer 4

After contacting technical staff in a branch of our company abroad in China, we've found that for the bulk of the systems they use, which require logins, they tend to stick to the standard ASCII characterset for usernames and passwords for these reasons.

Chinese keyboards generally have the QWERTY set up alongside chinese characters and users are able to switch between chinese and ASCII input methods easily to login to systems. For now, we will be leaving our system as it is and monitor additional cultures as they are added, handling any special cases that may arise.

More information on Chinese input methods can be seen on Wikipedia - Chinese input methods for computers