Email verification protocol(github.com) |
Email verification protocol(github.com) |
Check this profile for the email if you wanna ask for more info or get updates.
Source address verification doesn't really mean anything (no-reply@example.co.uk) and destination verification is obvious and as far as I am aware pretty much no-one doesn't do it already.
"delivery peers symmetric" - what does that mean?
1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.
2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from <insert site>" is enough.
3) The device receiving the verification message is often not the same device that initiated the process. It is very important that users are able to easily type out the code in the webapp, instead of what many do: require a link to be opened.
4) Alright, use email, but don't treat as a special or absolute means of contacting users. The whole "contact user" aspect should be abstracted to a point. Any messaging app that the user would like to use should be used. There are dozens of them, and all of them should be abstracted to the webapp. Managing api keys and integrations sounds like a nightmare, this is one big reason no one is doing it. But again, that's my gripe, this is a solvable problem, services and libraries to make it easier should exist, but where they don't .. the developers of the application should take on the costs associated with supporting them. Maybe not dozens but a handful of messaging protocols, based on target audience can be used (e.g.: Signal,Whatsapp, Weechat, VK, Telegram, Bluesky, Twitter) - 7 api keys to rotate once every few months and you've just made billions of potential users happy!
5) Perhaps the problem is a lack of a "secure address resolution layer" to messaging? Without requiring api keys and all of that, it should be possible to resolve the address of a recipient, encrypt a message to them, using their public key, and simply send it. Messaging apps should support a standard protocol of receiving external messages this way. The protocol should also allow including a "reply" address?
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
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, despite email being used for auth, as you correctly claimed, email clients aren't secured like authentication applications or password managers are. For most people, a compromise of their email account means a compromise of most of their other accounts.
Even furthermore, not only is email used for authentication, email is being used to revoke,reset and tamper with other authentication methods and account security in general. You don't just login to apps via email, your password, MFA, account changes,etc.. can all be done by someone controlling your email (and more and more, your phone number/SIM these days).
End to end encryption is all the rage on sites like HN, but I'm shocked when those same people have no problem using email for sensitive operations.
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
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 complicated helps the big and hurt the little in th long run)
Not verified but feels like a Google draft that closes the web.
The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.
So instead, there’s no verification mail and it’s the next message, the one that you actually wanted, that gets blocked or sent to spam.
The “privacy advantage” that the issuer can’t learn the identity of the application that wants to send mail seems to me to be a significant functional liability. If it instead produced a token that said to the email service provider “see, the message was invited”, now that would be useful. (It would raise concerns of its own, but it would at least be useful.)
Depending which privacy, currently if I input a email into xyz noone can trust that this email belongs to me. In the future every email input can verify if the mail belongs to me, that scream abuse and more new things that try to fix the old.
The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse
It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.
Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.
Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.
I think there is benefit to this because folding some identity primitives into the browser helps the user (in UX, in security). This was certainly true of password managers.
The other comments talk about how you will need to have a fallback. That is certainly true. But just because you have to have a fallback doesn't mean you can't improve things.
> Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)
But would they need to if they could trust info coming from the browser?
0: I wrote an intro to this here: https://www.infoq.com/articles/federated-credentials-managem...
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 this problem.
I worked authc/authz and security for a large fintech and we constantly butted heads against the growth folks. They fought hard and eventually won the right to do account creation and IDV without email verification. You don't have to verify your email until you're already making transactions, and that does wonders for growth. We're still accountable for all the stringent KYC regulations, of course.
Sounds like a useful and very effective filter to not create accounts for things that do not really matters to you.
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.
Then it's something maybe the customer isn't interested in the first place. Most of the time mail just works for me only issues are sometimes greylisting and it takes hours.
I can understand it from the company side, but not sure how well it really works when someone use a mail app on mobile and on desktop not even logged into the mail account.
* It's not clear if this service would be provided by a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.
** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+<whatever>@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.
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 staff. Again, not a bad proposal but perhaps not very useful in practice.
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).
This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") by making email verification exponentially more complex, with only one correct flow, and will only work for domains that have opted in and configured this protocol.
Importantly, the protocol seems to rely on 1st party web cookies, which means you could no longer run a "pure" MTA that offers IMAP; you would need to have some web interface where your users can log in, even if there is no webmail functionality.
The bigger question is: why would the company who is hosting the email have any economic incentive to invest time and money in implementing and maintaining this protocol which currently has zero adoption? It's a chicken-and-egg with no upside.
I agree with a lot of what you are saying, but I think the main motivation is actually trying to reduce friction for the user to verify their email, which is good for the user, because it makes registration easier, and good for the company, because less users bounce at the email registration step.
But yeah, this is quite complicated, and there isn't a lot of motivation for email providers to implement it.
It’s not about efficient, effective solutions. It’s about control. Something you have to look at with WICG and W3C is the source of proposals and drafts.
* It's putting surveillance companies even more in the loop, building on the recent "log in with [surveillance company]" buttons, while existing login methods are destroyed through dark pattern practices or simply removed.
* It can be a ready-made platform, waiting for the next authoritarian government directives that say, now that everyone is hooked up or can easily be hooked up, turn on oppressive feature X, Y, or Z for all targeted Web sites/people.
This looks broadly similar to that, but with some newer primitives (SD-JWT) and a focus on autocomplete as an entrypoint to the flow. If I recall correctly, the entire JOSE suite (JWT, JWK, JWE, etc.) was still under active iteration while we were building Persona.
And hey, I applaud the effort. Persona got a lot of things right, and I still think we as an industry can do better than Passkeys.
For historic interest, the Persona After Action Report has a few key insights from when we spun down the project: https://wiki.mozilla.org/Identity/Persona_AAR
I like the idea in general - an OIDC-like flow without needing any a priori setup. But, the RP has only a signed token with the pubkey in DNS, so this doesn't prove anything about the user unless the RP also verifies against some trusted and known email providers. This is absolutely awful for the Internet and makes sure power stays concentrated. PLEASE don't let this become a thing.
Second, this doesn't improve privacy. Most RPs will send an email right at signup, or soon thereafter. Thus the email provider does learn of the individual's association with that web application.
A last issue that's immediately obvious, is that you have to use a webmail interface.
But after some work the team scoped down, to focusing on email verification. I think that's what lead to this spec? https://groups.google.com/a/chromium.org/g/blink-dev/c/rwu9w...
This seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.
https://github.com/WICG/email-verification-protocol/blob/mai...
could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims.
I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.
No way in hell I’m gonna learn another of these nightmarish protocols unless this is somehow much much better.
LOL WUT??
This is also ideal in “war dialling” eMail servers to get accurate lists of what eMail accounts exist on said server. This has been the case since marketing first hit the Internet.
Do you really want all of your legitimate eMail addresses to end up on spam lists? Because this is how you get complete and unabridged lists of your domain’s valid eMail addresses onto spam lists.
It’s why my own eMail server is set up to quietly confirm and accept any and all eMail sent to the domain - regardless of username employed. Even invalid eMail accounts get confirmed and incoming eMails to them get accepted.
Anything not sent to a valid account then drops into a catch-all account for further processing. Occasionally I’ll get eMail where the username was misspelled - it happens - and I just forward it to the appropriate family member.
The rest get reported as spam. And I enjoy making every last report. Enjoy ending up on a blacklist.
Not really, as I can enter any email on a service login page that uses magic links for auth. The owner of that email will receive the login link but that doesn't mean they tried to login on that system.
A user may make a typo in the email, and that email might still be a valid email know to work (but for another, unrelated person). The user's email agent (such as GMail or Outlook) can mark the email unimportant and make it hard to notice, or even mark as spam. All these issues are much better to find out and iron out before the user sees themself unable to communicate, or successfully bound to an email they cannot access.
The whole point of email verification is to make certain that a channel of alternative communication exists for a case when the user would be unable to identify themself normally, for whatever reason. A working email alone is not always sufficient for successful credentials reset, but almost always it's much easier to when the user has it.
That won't verify. The issuer should check if the request has valid session cookies for the e-mail-address that should be verified. This also implies that it just won't work for any service that uses sessions with a short timeout.
This was originally thought up a couple (5-6) years ago along side fedcm and privacy sandbox, but before SD-jwt was full baked, so it wasn't as clean. The use of SD-jwt is much better for privacy.
How can you avoid revealing the application through the `Origin` header?
Or is this one of those things they will shove in our faces whether we like it or not?
PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
There's also a proposal to add stateless ephemeral clients.
- whom the accept mails from under which conditions - who's blocked and why - perhaps hashed-and-salted-email-addresses for verification - how much spam (as the receiver understands it) happened from where - that you produce tokens with hashcash, so you unknown senders can verify themselves with that per mail/receiver
I'll put this on the backlog of things to implement if I'm incredibly bored and want to weaken the security of my infrastructure.
Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?
If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.
The protocol proposes to alleviate a UX burden. The back and forth.
it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.
Neither, I do it so I can track which companies sold my email address on without my permission so I can put them on my shit list / report them to my government / shame them on the internet / whatever.
> The protocol proposes to alleviate a UX burden. The back and forth.
That seems to be _one_ aspect but that assumes you're logged into whatever email verification provider is in use.
> it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.
You assume that it's the email provider which has to implement this, which isn't so clear to me.
Only the email provider can attest that + addressing is in place, if a third party is involved, they can only explicitly match on full email addresses.
Like I said in my original comment, if it's the email provider that has to implement this, then the bulk of my issue is gone. Aside from the fact that now, as my own email provider, I have to implement this protocol somehow (easier said than done given my current infrastructure approach is aimed towards moving as many things into a non internet facing network).
Tough beans?
At this point the password is pointless, you might as well just use the email address. Or perhaps a distinct username and email address, but then there would probably be a “forgot username” workflow making that as pointless as the separate password.
* prevent signing up for someone else (validate it is you who owns the email)
* poor man's mfa, although please allow me to use totp instead (probably the three most legitimate reasons from a user perspective, email validation prevent you from making a typo)
* send ads and notifications (legitimate from the provider's perspective, they want campaigns to succeed, email validation makes them sure emails land)
* reduce throw-away or bot accounts
It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
That seems to be a better option for bots than for actual users: if you care about the account, you probably would not want to make its password resettable via a service like that. Or even via a regular email provider you do not trust, and those could easily be the only kind available.
Bots have no trouble signing up with @mybotfarm.example addresses.
/s?
Example: you can make orders from mlb online without verifying your email, and then you get marketing emails regularly. In that case, I was able to call the very senior citizen who thought he could just use any address he wanted.
I can't remember the dating app that let someone sign up mobile using my email address... I hijacked the account (password recovery) and changed the prompts to "I'm an idiot that doesn't know how email works." ...
Less easily than you'd think.
You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers.
Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: <* or your domain>` and `Access-Control-Allow-Credentials: true` in its response.
Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content.
> I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?
Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol.
Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.
<my initials>-site-<companyname>@<my domain> go to my personal mailbox
<my partner's initials>-app-<appname>@<her domain> go to my partner's mailbox
<daughter initials>-account-<entity name>@<my domain> go to my daughter's account
Sure you could in theory set up the server side verification mecanism for these pattern too. I am just stating that the +suffix stuff is not the only way used.
So it might get some traction, and finally break the monopoly of "Login With Google" buttons.
You have a business relationship between the company and a person. Whether that person remembers the password or not is immaterial to whether they have the legal right to anything they purchased in the app.
But let's be real - nobody actually does that.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address is required to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, all other things held equal, then strictly speaking it is more robust.
The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found an identity provider yet that wouldn’t support that. Yes, that protocol has way too many knobs providers can fiddle with. But it’s absolutely doable.
code_challenge_methods_supported
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 using your flow to "ddos" some random domain...?
Not sure they’d let you register foo+1 at Gmail or force you to choose foo or foo1 and plus accordingly later
Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?
Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite difficult.
OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.
The problem is that no one that mattered implemented them.
If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.
Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.
Oooh I like this idea!
The signup protocol and user flow is the same if the feature is supported or not. You just skip a step if the convenience feature is supported.
With SSO the user is inconvenienced with an additional option at sign up and login, and there's the risk of duplicate accounts. Also stronger vendor lock in.
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 when it goes south once
If they do it correctly, that shouldn't be possible.
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.
random @ SpecificDomainOnlyYouUse .tld ?
It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
> It "generally" doesn't, because the average user isn't randomly generating usernames per-site
What other people do, whether average users or not, doesn't matter. When average user Alice is registering accounts on Websites A and B, the fact that average user Bob doesn't use different usernames for his accounts doesn't change the fact that if Alice would have otherwise registered account agirl on one site and pie_maker26 on the other, but instead has been forced to enter her email address, then that has a non-zero effect on risk.
For the claim as stated to be untrue, the difference in risk would need to be zero.* But it isn't zero. The claim as stated is true.
> For it to practically make a difference, you'd need someone who cares about […]
That's not true. Users who are exposed to lower risk by accident are still exposed to lower risk. It's not a prerequisite for the user to care at all, nor does it require them to understand any of this or to be trying to adhere to any particular scheme to achieve a certain outcome. The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk. Intent doesn't matter.
* or it would need to be somehow less risky when email addresses are required in place of where a username otherwise would be, but that's not the case, either
I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite? Moreover if we're really accepting "whether average users or not, doesn't matter", I can also say that using emails doesn't decrease security because you can use randomized emails, as others have mentioned. At some point you have to constrain yourself to realistic threat models, otherwise the conversation gets mired in lawyering over increasingly implausible scenarios. For instance, by asking for emails at registration, you can more easily perform 2fa, whereas you can't do that with only a username/password combination[1].
[1] before you jump to say "but can ask for an email with username/password too!", keep in mind the original claim that username/password is better was in response to a comment asking "Why must apps require email?".
What?
> I can also say that using emails doesn't decrease security because you can[*] use randomized emails
That _doesn't_ _matter_. Viz:
> The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk.