Prevent homographic usernames

new features go into devel version.

Changing version and title to be more descriptive.

It might be nice to have an admin setting for "prevent homographic usernames" which would then trim and transliterate a name and see if a similar user exists before allowing accounts to be created. I've seen this before as "admin " (note the space on the end).

Bumping version. No idea if this is still an issue.

Michelle

This is still an issue in HEAD.

This can use the username field introduced in this issue:

http://drupal.org/node/279851

and should be inserted into user_validate_name() in user.module

Here's a nice paper describing this security problem:

http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf

phpBB has solved this problem by using 'username_clean' which is a sanitized version of the login/display name that's stored in 'username'. It uses the 'utf8_clean_string()' function defined in: http://code.phpbb.com/repositories/entry/5/trunk/phpBB/includes/utf/utf_...

Not sure if this should be set as 'bug report' instead of 'feature request'. IMHO this is a security problem, not just something that's "nice to have" :)

This has been accepted as a task for Google Code-In:
http://www.google-melange.com/gci/task/show/google/gci2010/drupal/t12904...

What this means is I'll be mentoring a student working on this task. While the initial work will be a D7 contrib module, webchick has asked for a canonical issue here to facilitate discussion with the community. Once the D7 module is working, we can then discuss how it might be incorporated into core for Drupal 8.

from the other issue:
Hm, homographic logins would be usernames spelled with letters that look very similar. However, the transliteration module attempts to transliterate letters into the Roman alphabet, meaning that (1) letters that bear no resemblance to other letters get transliterated, and (2) letters that do bear a resemblance, but sound differently, get transliterated into a different letter than their homographic equivalent in the Roman alphabet.

Thus, I don't think the transliteration is the right solution to this. I'm not sure of any other datasets that deal with this specific problem though.

An example where this would be a problem is the screenshot of the transliteration module: http://drupal.org/files/images/translit_0.thumbnail.png - looking at the first word, all letters but the "o" look completely different, and it would be pretty easy to distinguish (visually) usernames. If phpBB has a list of letters that look similar, we could use that.

The problem, basically, is what we're looking for is not transliteration, but a list of homographic letters. Transliteration is taking the sounds from one alphabet and putting them in another. We're not looking for the sounds at all -- this issue concerns the appearance.

we can steal PHPBB's list, which in any PHPBB3 is in includes/utf/data/confusables.php

The PHP intl extension provides a Spoofchecker::areConfusable() method that could be used for this but comparing the news username to every existing user would probably be expensive.

Symfony also provides a NoSuspiciousCharacters characters constraint (which uses Spoofchecker::isSuspicious() internally): https://symfony.com/doc/current/reference/constraints/NoSuspiciousCharac...
This is probably a good solution but it requires setting the expected locales (having Cyrillic letters in usernames on a Russian websites would not be suspicious for example). I supposed we could configure it using the enabled locale on the website.

Added a basic implementation.
The main caveat is that it heavily depends on the languages activated on the website (because that's the way NoSuspiciousCharacters and Spoofchecker work).
If we find this too restrictive, we could also use NoSuspiciousCharacters without restricting the allowed locales, it would still be useful to detect mixed character sets and invisible characters.

I'm not sure the failing AssetAggregationAcrossPagesTest is related?

Removing tags that are no longer relevant.
The new solution is well documented, but I'm not sure about the tradeoffs here, tagged for product manager review because of that.

I just noticed Drupal does not require the intl extension.
NoSuspiciousCharacters will throw an exception if this extension is not available.

We could either:

• Require the intl extension
• Skip this constraint if the extension is not available

I added the intl extension to dependencies.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I rebased the MR.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I rebased the MR.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I rebased the MR.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rebased and fixed conflicts, but there are some pipeline failures.

I fixed the tests.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I merged the latest main.