Currently a valid email address can be registered as username without any ownership verification. This leads to a multitude of problems including consistency/uniqueness and spoofing.
#111317-83: Allow users to login using either their username OR their e-mail address → :
At a minimum, I think we need validation when new users register that their username matches neither an existing username nor an existing e-mail address.
While a bit better than the status quo, this doesn't cut it leading to - em, sorry - superficial fixes like the proposal in 🐛 Allow password reset on account with the username matching another email; prevent registrations that match another account Needs work which introduces code bloat and new privacy problems, while still not solving the fundamental problems.
It neither is enough to check usernames for uniqueness upon account creation nor upon changing the account name.
Registering with a username that could be an email address always comes with a risk of identity fraud or blockade, if the potential email address isn't verified.
Imagine someone registering with the username 'bill.gates@microsoft.com' or 'dries.buytaert@drupal.org' with her real email address given as 'spoof@xxxhost.ru'.
Regarding the identity fraud case: Bill Gates might not be registered on our site yet, so the address is allowed. Still the fake Bill could post in the name of Bill Gates, and even with a (misleading) sign of being verified.
Regarding the blockade case: Bill Gates might not be registered on our site yet, so the address is allowed. But if tomorrow Bill Gates wants to register as 'Bill Gates' with his email address 'bill.gates@microsoft.com', he will be disallowed to do that because someone else fraudulently blocked Bill's real email address from being registered. Now Bill doesn't only have to live with the fact that there's someone else posting spam in his own name, but he can't even prove that the email address in reality belongs to him.
So what could be our options?
Needs work
11.0 🔥
Last updated
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This is still an important improvement and security precondition for ✨ Allow users to login using either their username OR their e-mail address Active . The current situation also allows for easier social engineering, if an email address doesn't match the username or even the email address or username of someone else.