Auto-Element: Instant account registration and bookmark-based account login, for easier new user onboarding.

[techmindful]

Notes: Implemented the concept of auto-account for Element. I've made a video demo here: https://vimeo.com/597549392. Auto-account is the idea that a web service, whose purpose is communication, social media, and the like, can make the experience of onboarding new users easier, by inviting a new user with a link. After the new user visits the link, the web service generates a random username and password, automatically uses them to create an account for the new user, encodes them in a new link (account link), and sends it back to the new user. The new user saves the account link, in a convenient place like a bookmark. Then whenever the user needs to log into their account, they can visit the account link. The web service extracts the username and password from the account link, and authenticates the user. Auto-account saves the user from having to come up with a new username, and secure enough password.

There's another pull request on matrix-org/matrix-react-sdk which is necessary for this feature to work: matrix-org/matrix-react-sdk#6741

---

Here's what your changelog entry will look like:

✨ Features

• Implemented the concept of auto-account for Element. I've made a video demo here (#18900). Contributed by @techmindful.

[turt2live]

clearing auto-review for partner PR

[novocaine]

This is a pretty interesting idea, and it'd certainly be a great thing to be able to onboard users rapidly. Some thoughts:

• Minimising number of clicks is really cool
• Auto-generating an available username is a good idea, ideally based on some other PII about the user so they get something nice - based on their email or real name, say

That said, storing the password in a bookmark just isn't sufficiently secure - bookmarks aren't considered very private so aren't generally stored encrypted, and are commonly synced to cloud services or shared en-masse with other users using bookmark sharing apps. So users would too easily lose control of the their credentials.

I think this might be quite interesting if it were paired with passwordless auth - which would mean the user doesn't need a password at all. This might be more easily implemented with https://github.com/matrix-org/matrix-doc/issues/2615 - but of course its a much bigger lift.

So while this raises some interesting ideas, unfortunately I think it's a bit of a non-starter. This probably could have been caught during a design discussion on #element-dev.. particularly when there's some security issues to work through, could I humbly suggest you raise ideas there first, to avoid doing too much work on something that might not be approved?

[techmindful]

@novocaine Thanks for the review! Don't worry, I was just having fun hacking with the source code, not expecting anything. I will strike a conversation in the dev rooms first for next time though.

You brought a great point that it can be unsafe because users may sync or share their bookmarks. I'm not used to doing that so I fell short on that perspective. To counter that, I then briefly thought about adding in a helper service. It sits on the server with an encryption key. When the auto-register happens, the service encrypts the credentials, and then sends it inside the link. When user auto-logins with that link, the service decrypts it and gets the credentials, and passes it to the frontend or the homeserver. This way, the user can store the link in the bookmark, which contains encrypted credentials. Although it is adding in some extra steps and complexity. What do you think?

[novocaine]

@novocaine Thanks for the review! Don't worry, I was just having fun hacking with the source code, not expecting anything. I will strike a conversation in the dev rooms first for next time though.

You brought a great point that it can be unsafe because users may sync or share their bookmarks. I'm not used to doing that so I fell short on that perspective. To counter that, I then briefly thought about adding in a helper service. It sits on the server with an encryption key. When the auto-register happens, the service encrypts the credentials, and then sends it inside the link. When user auto-logins with that link, the service decrypts it and gets the credentials, and passes it to the frontend or the homeserver. This way, the user can store the link in the bookmark, which contains encrypted credentials. Although it is adding in some extra steps and complexity. What do you think?

I suggest you follow up in #element-dev, but from my pov, you generally wouldn't want to store encrypted credentials on a server which also holds a decryption key because the admins of that server then have access to people's passwords. Also, if the server is compromised, the attacker will probably gain access to the key as well as the encrypted credentials. So most systems will only ever store irreversible hashes of passwords.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

[techmindful]

@novocaine From the top of my mind, I think the server can still only store hashes of passwords. Regardless, I think the real issue that you pointed out remains: User may share/sync bookmarks. If a user syncs the account bookmark with an insecure bookmark sync service, and the service later suffers from a data breach, then whoever gets their hands on the bookmark effectively gets the access, whether the bookmark contains a plaintext password or an encrypted one.

This seems to need more thought 😅 I'll try to brainstorm with more people.

[novocaine]

I don't think we're going to go to this way, so closing the PR.