https://bugzilla.wikimedia.org/show_bug.cgi?id=9816
Philippe Verdy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Priority|High |Normal --- Comment #25 from Philippe Verdy <[email protected]> 2009-11-14 18:32:40 UTC --- I also don't like captchas. But please don't force users to use at least one digit or something like that, because instead of increasing the security it will actually reduce the search space. Instead I propose this: (1) convert the password at least to Unicode NFC (and apply any other suitable normalization like compression of whitespaces). Possibly even to NFKC (to avoid compatibility characters). If that password, after normalization, is different from what the user typed, make sure to inform the user to confirm that this is what is happening. (2) compute the basic size S of the alphabet : - if a lowercase ASCII letter is used anywhere in the password, add 26 to the the alphabet size - if an uppercase ASCII letter is used anywhere in the password, add 26 to the the alphabet size - if a decimal ASCII digit is used anywhere in the password, add 10 to the the alphabet size - if a ASCII punctuation is used anywhere in the password, add the size of this ASCII punctuation subset to the alphabet size. - on localized wikis, consider other subsets consisting in non-ASCII letters used in their alphabet (take CLDR data appropriate for that language, remove the characters already part of the previous subsets, and then add the remaining characters to the basic size S). - if other Unicode characters are included, accept them individually by adding 1 to S for each distinct character (but inform users that they may have difficulties to connect from some environments with such password). (3) take the base-2 logarithm of the alphabet size, and multiply by the password length (N). This gives the raw "bit-length" strength of a password. In other words : raw bit-length strength = log2(S)*N (4) if a space is accepted in the password, it should just occur in the middle and not at the begining or end and not in sequences of more than one space. Because of that, a password of length N cannot contain more than (N - 1) DIV 2 spaces, which adds ((N-1)DIV 2)*log(S+1)/log(S) to the row bit-length strength. Of course you can check that basic default passwords is not used (like "0000" or "1234" or "password" or "admin" or the username itself, or any word contained in the user's own public identity like hist public first name or last name, or any word contained in his user page, or in the first 1KB of his talk page). But using any large dicionary to forbid passwords may actually reduce the bit-length strength rather than increasing it, for brute-force attacks (even if it protects from dictionnary-based attacks), by allowing them to skip too words contained in that known dictionary. And it may also forget many wellknown common words (including first names) from other foreign languages (my opinion is that the dictionary used should just be built from the terminology used in the MediaWiki messages stored in the "MediaWiki:" space, in all its supported languages, and for each extension that is activated in the wiki where the account is created). However, even if a password is not strong enough, users should still not be forbidden access completely: he should be denied from using the secure server, but will be informed that his password is not strong enough to be used there, but he will have the option to go to the non-secure servers. I also suggest then that the user's Preferences panel include such password bit-length strength (computed like above) and a visual color bar indicating him the basic security of his account, and if the bitlength strength is suitable for identification on the secure server. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
