Ages ago we intentionally configured MTA's to prevent enumeration and validation of email addresses on purpose. This appears to be a convoluted way to unwind that change and in my opinion would be heavily abused by shady email marketing groups on day 1. With all due respect I would never implement this in a company and would fight it. I choose my battles carefully before presenting them to the board until groups such as NCC [1] have reviewed the implementation concepts and details. All it would take is one poorly coded application using this incorrectly to be abused. i.e. devil in the implementation details or otherwise known as the weakest link. Having NCC validate every single implementation is going to get very expensive.
Email verification protocol
141–150 of 151 posts
Re: Email verification protocol
#142Seems like Oidc os much easier to implement and use by the user.
Re: Email verification protocol
#143The ideas proposed in here aren't bad, but it does seem like you'll need to maintain two user flows as a site owner because: 1) Not all email providers will implement this, and 2) Users may not be signed into their email at the moment they signup As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support…
I thought Mozilla Persona aka BrowserID handled this email validation well with a fallback provider that used the same flow (and also implemented the OIDC work for obvious existing social providers like Gmail/Google Accounts). Though obviously not well enough because that fallback provider was seen as a large expense and shutdown without a replacement killing the Mozilla Persona effort.
But that does relate to I keep wanting an email claim for Passkeys. A user's browser/OS could verify an email address once and then associate it with a Passkey. Passkeys might be a good place for that (as Persona/BrowserID suggested). Obviously some browsers could lie about verifying the email address in the claim and there might still need to be more steps to it, but if you are already taking Passkeys it doesn't necessarily add an entirely different flow to accept a verified email claim from a Passkey (and/or decide you don't trust that Passkey's claim and trigger your regular verification code flow).
Re: Email verification protocol
#144Make everything what works complicated. There is no advantage. "User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…
> There is no advantage. I can't tell you how many times email verification context switches made me completely lose track of what I was doing. There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login. There are probably dozens, maybe hundreds, of services I never finished registering for all on account of t…
What's worse is that the email is often delayed at the sender (cheap bulk email services) or the receiver (gray listing), but for no reason I can fathom have a short expiration date.
What's worse they are often unique AND delivered out of order AND have no timestamp or sequence number. So you get to guess which is the newest, using any other fails, and the ones that succeed often time out before they can be used.
Having an expiration date as short as 15 minutes seems insane and counter productive.
Re: Email verification protocol
#145Earlier quoted context omitted.
1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing
> Email isn't used for auth? I didn't say that, you added that part. It is used for auth. it isn't secure. Email is less secure than SMS, unless you encrypt your email (even then..). With email, there are multiple middle parties that can just read the message. Forget malicious insiders, it is more than reasonable to assume at least one MTA out there is compromised. Mail server CVE's aren't that rare. Furthermore, des…
Sms travels through air, so it's less secure.
Also email is usually encrypted, MTA are application layer, not routing layer, and they can onlu see headers.
2fa is nice, but the first factor is usually email.
But whatever, maybe the world is wrong
Re: Email verification protocol
#146Earlier quoted context omitted.
Pkce is trivially easy to announce support for, you put it in the issuer metadata. code_challenge_methods_supported https://datatracker.ietf.org/doc/html/rfc8414#section-2
With metadata endpoint, things become much easier, that is true. Though how would you implement it? Like, user comes to your website and wants to sign in with some foo.bar provider, do you force the user to paste in the domain where you go look for the metadata? What about facebook or google, do you give them special treatment with prepared buttons or do you force user to still put in their domains? What about people…
Fedcm offers some hope here, where the browser gets some capability to announce the federation domains to the RP. It's not straightforward though, of course. In this case though it's inverted - you are providing the url of the MCP server, and the MCP server is providing the url of an authz server it supports. The client is uses the metadata lookup to know if it should include PKCE bits or not.
Re: Email verification protocol
#147Earlier quoted context omitted.
Not everyone uses an email provider that is also also an OIDC provider.
Additionally, some corporate or personal policies might prefer to NEVER use SSO, even if it is sometimes accepted. I hate being presented with option to login with email or login with Google, and I don't know which I signed up with. God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost…
> God forbid I accidentally make an account with SSO and another with email but the same email.
If they do it correctly, that shouldn't be possible.
Re: Email verification protocol
#148Re: Email verification protocol
#149Earlier quoted context omitted.
Additionally, some corporate or personal policies might prefer to NEVER use SSO, even if it is sometimes accepted. I hate being presented with option to login with email or login with Google, and I don't know which I signed up with. God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost…
> God forbid I accidentally make an account with SSO and another with email but the same email. If they do it correctly, that shouldn't be possible.
You can have both a gmail and a google workspace account with the same email, but I'm sure someone can do better than Google.
Also I'm pretty sure that since google is itself an SSO provider, this add another layer of clusterfuck that I don't even want to think about, regardless of whether there's a clean implementation or not, I don't even want that on my mental capacity.
Re: Email verification protocol
#150Earlier quoted context omitted.
I personally use a different, but still perfectly compliant suffix character. So just simplistic +suffix filtering isn’t complete. I’ve also considered using a double suffix and having the first one be required, so if someone cut off all suffixes it would go into junk anyway.
I have a script which generates random addresses for each site, with a database to lookup what E-mail belongs to each. No regexing away that!
Nice!
random @ SpecificDomainOnlyYouUse .tld ?