Invitations are links now

Inviting somebody to work on an application in the Elchi console used to work by address. You typed a colleague's email address; if an account with that address existed, it joined at once, and if not, the invitation waited until somebody signed up with that address. From this release, an invitation is a link instead.

What was wrong with the address

Until this release, EAuth never checked that an address belonged to the person who typed it. Anybody could register an account with colleague@yourcompany.ch before your colleague did. If you then invited that address, the seat went to whoever held the account, with the role you chose, admin included.

We found this in a review of our own code, not through an incident. Nobody outside Elchi Studios had an account when this release went out, so nobody outside the company could have been affected. It still had to go before anybody relied on it.

This release closes the obvious hole a second way as well: EAuth now gives no application, our console included, an account whose address has not been confirmed with a link sent to it. That still would not make the address the right key. A confirmed address proves that somebody reads a mailbox. It does not prove that they are the person you meant: mailboxes are shared, forwarded and inherited. An invitation should go to the person you chose, not to whoever turns out to control a string.

How it works now

When you invite somebody, the console gives you a link. You send it to them yourself, through whatever channel you already trust.

• The link is shown once. We keep only a digest of it, like every other credential, so nobody can read it back later, us included.
• It works once, for seven days.
• The address you typed is a note of who it is for. Inviting the same address again replaces the link, so a link that went to the wrong place stops working.
• Opening the link shows the invitation and asks. Joining takes a click. Mail scanners and the link previews of messaging apps open links on their own, and they must not use up an invitation meant for a person.
• Somebody who is not signed in signs in or creates an account first, and joins right after. A new account confirms its address on the way, with the link EAuth mails, and comes back to the console. If that takes more than an hour, the invitation link has to be opened once more; it still works for the rest of its seven days.
• A link dies with the authority of whoever made it. If the admin who invited somebody is removed from the application or loses the admin role, their open links stop working.
• Joining never changes a role somebody already has. An old link cannot quietly promote or demote a member.

The rule about authority came out of a second review, after the first version was finished. Without it, an admin who was about to be removed could invite a spare account of their own, and use the link to get back in.

What it costs

You have to send the link yourself. We do not email it, on purpose: you know which channel your colleague expects a link on, and an invitation arriving by mail from us would be one more message worth copying for anybody who wants to phish your team. Sending it yourself is a few seconds of copying, and the console puts a button next to the link for that.

Invitations made the old way, if there were any, expired with this release, because nobody holds a link for them.

One pattern, three places

The same kind of link now carries three things: an invitation, the confirmation of an address, and a password reset. Each is 256 random bits, stored only as a digest, and works once for a limited time: seven days for an invitation, a day for a confirmation, an hour for a reset. Opening a reset link or an invitation never spends it on its own; only the person's click does. Confirming an address is the exception, because whoever can open mail sent to that address is exactly who the confirmation is about.