bug: Auth allows invalid emails

[taterhead247]

Provide environment information

chromium desktop

Describe the bug

I was cruising the Sendgrid logs on a Saturday night because I'm cool. I saw auth tried to send an email to "xxxx@gmail". The .com was missing. I tried it, it let me attempt login with "test@d". It looks like it's only checking that there's an @ and that there's a character before it and a character after it. It does not ensure there is a period after the @.

Link to reproduction

auth.f3nation.com

To reproduce

Try to log in with "test@d".

Additional information

before trying to auth someone, it should confirm it's a valid email with x@x.x

[BlueDreaux]

Interestingly enough, the regex used by the HTML 5 "email" input type allows for the optionality of the dot-atom per the RFC5322 specification. Though, per the same specification, context of how the address is used should govern which of the addressing protocols should be used. For the purposes of auth in this project's use case I would agree that we'd want the dot-atom definition for the domain to be non-optional.

The regex implemented by the HTML5 "email" input type specification:

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

Would need to be replaced with an altered variant of the last * to a + and become:

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)+$/

Hopefully this comment's purpose is understood as intending to bring clarity on how the less constricted address validation might have been implemented (going with the more commonly used validation), why the choice to allow the broader address spectrum isn't necessarily a bad one given potential edge cases, and why we might want to break with the more commonly used validation for this use case in authentication and make the dot-atom definition of the domain non-optional.

We may also want to further bound the sub-domain nesting of the domain dot-atom (and even the dot-atom of the local-part), not as a matter of allowing the specs to guide us clear of unforseen problems, but as a matter of bounding the regex's running evaluation compounding a potentially improperly handled submission that turns into a streamed buffer attack. I think a {1,32} is more than adequate to handle any realistically thought through edge cases while bounding how much the regex evaluation can be leveraged to compound the effects of such an attack. Doing so depends on how directly input is passed to the regex evaluation both now and after future changes as well as whether validation is done strictly on the client-side (bad idea) or server side.