Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google Gmail -- dot ( . ) in local part & existing user's email (account) #2270

Open
dev-101 opened this issue Jun 27, 2018 · 8 comments

Comments

@dev-101
Copy link
Contributor

commented Jun 27, 2018

Hi,

Something recently happened that made me think about this and we should definitely consider changing our email validation mechanism.

As you might already know this, Google's Gmail address does not care about dot symbols in local parts, so, for example:

my.email6534636346@gmail.com

is exactly the same as:

myemail6534636346@gmail.com
M.y.E.m.a.i.l.6534636346@gmail.com
etc.

You get the idea. All 3 examples above, from Google's perspective, are the same and only email address (account).

Now, while all of above are technically different, in case of Gmail (at least), when checking if user is already registered (exists) we should consider this technicality and remove dots before comparison.

While another person / potential user cannot* undermine original's person's security in any way if account confirmation is required IN OSCLASS's User settings ("Users need to validate their account"), and unless intruder has access to original person's Gmail account, and because Google prevents registering another email address with the different dots configurations (it will detect and report that email account as not available), we should avoid it anyway, because the original person will still receive email notification about registration (and addressed to a different user), because, again, dots don't count in gmail. So, it may be confusing to the person who was registered first with it.

If account confirmation is not required in Osclass (per admin's configuration), then we might have a problem.

This is a problem some big companies have, too.
So, a person may receive messages / notifications addressed to different persons (e.g. name or username), which may raise suspicion and confusion, to say at least.

I know it may get hairy with all different possibilities out there, but Gmail is so dominant today, that we can't simply ignore it and we should make an exception in this case at least.

resources (there are many):
https://support.google.com/mail/answer/7436150?hl=en | Dots don't matter in Gmail addresses
https://stackoverflow.com/questions/14865869/do-all-email-providers-ignore-periods-in-front-of

@garciademarina

This comment has been minimized.

Copy link
Member

commented Jun 27, 2018

Now, while all of above are technically different, in case of Gmail (at least), when checking if user is already registered (exists) we should consider this technicality and remove dots before comparison.

I don't think it's a good idea, I use this exact feature for this purpouse, to be able to have two accounts.

I don't see the issue here, if I make a variation of my gmail address, only me will receive the email. As you said this is how gmail works.

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

Hi Carlos,

I had that exact paragraph written above, but just moments before posting I decided to delete it.
Now, you, as a developer knows the loophole, just as spammers and malicious users do. Who can stop them using same email address now?

I would rather have more secure system, then this unplanned feature for admin/dev.

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

Also, if admin does not check the option to require account confirmation, then the 2nd/3rd/Nth user/account will be able to post items, subscribe to alerts, contact other users... Imagine the confusion in that case, it is a viable possibility.

edit: screenshot added

osclass-admin-dashboard---users-account-validation

@garciademarina

This comment has been minimized.

Copy link
Member

commented Jun 27, 2018

As far as I understand,

If an account carlos@gmail.com already exist.
Gmail will not allow any address like: c.arlos@gmail.com, ca.rlos@gmail.com, and all "gmail" valid address.

If this is true, I don't know where is the problem. Maybe I miss something.

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

Yes, I have already written that in my issue opening. That's the part where Google protects you, but it may not be enough (read my reply above).

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

Actually, now I realize what a mess Google created by this (by not following the standard).

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

I know you are looking at this from a developer & convenience point of view, that's why it should be easy for you to disable validation code regarding Google/Gmail in an instant.

However, switch to production mindset for a moment, and put yourself in the shoes of a user who just starts receiving weird email notifications. What will that user do? In best case scenario, it will contact admin/support and ask for security check. Ordinary users barely know what email is, let alone the difference or importance/non-importance of dot (.) in it.

@dev-101

This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

We can use filters/hooks. Simplest option is to just modify it in UserActions, during registration stage.

We already have this:

            $email_taken = $this->manager->findByEmail($input['s_email']);
            if( $email_taken != false ) {
                osc_run_hook('register_email_taken', $input['s_email']);
                $flash_error .= _m('The specified e-mail is already in use') . PHP_EOL;
                $error[] = 3;
            }

As system will not allow multiple account registration, we don't need other options (e.g. adjusting the model and other parts related to Item).

edit: unfortunately, it will also require other modifications, as well (in the model, particularly, to take into account comparison of all dots occurrences, and ultimately store dot-free version only in database). And, that complicates things even further, as login needs to take this into account, as well, so that initial user don't have issues because of removed dots. Oh...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.