Email-First Access: Why We Ditched Passwords

When we designed ShareAndGo's access flow, we deliberately chose to avoid passwords for guest users. Here's why, and how email-first access actually works.

The password problem

Passwords are a terrible solution to authentication for three reasons:

1. Users hate them. Every "create an account to view this document" prompt is a friction point. Some users give up. Others create accounts with weak reused passwords. Neither is good for you.

2. They're insecure. Most breaches involve credential stuffing — attackers taking passwords from other leaks and trying them elsewhere. If your sensitive document is behind a password, and the user's password was leaked in some other service's breach, your document is one step away from exposure.

3. They're hard to manage. When someone needs access to five documents over six months, they need five passwords. When they change jobs or leave, you need to remember every password they had.

The email-first alternative

Here's how email-first access works in ShareAndGo:

1. The admin creates an access link for a specific email address
2. The recipient clicks the link and is asked for their email
3. We send them a six-digit code to that email
4. They enter the code and get access
5. Session lasts until they close the tab or 15 minutes of inactivity

No password. No account creation. No app to install. Just prove you control the email address that was authorised, and you're in.

Why this is more secure

At first glance, email codes look weaker than passwords. But they have a property passwords don't: the code is single-use and short-lived. Even if someone intercepts it, they have maybe 10 minutes to use it before it expires. And because the code goes to a specific email, you're actually authenticating email-account-control, which is a much stronger signal than a self-selected password.

Compare this to a traditional password flow. A password is long-lived (often unchanged for months or years), gets reused across services, can be stored in insecure places, and can be stolen without the owner noticing. Email codes eliminate all of those failure modes.

When we add 2FA

For admin users (people managing data rooms, not just viewing them), we also require TOTP-based two-factor authentication. This is the "something you have" factor on top of "something you know" (your Google account password). Admin accounts are higher-risk, so they get higher-security authentication.

Guest users don't need 2FA because the email code already provides the "something you have" factor — control of the email account.

The user experience benefit

The practical effect: we get a lot less friction. Users don't bounce off the access flow. They don't create throwaway accounts. They don't complain about password policies. They enter their email, type six digits, and they're reading the document.