Back to Blog
EngineeringFebruary 2025

Why we chose passwordless authentication

Magic links are more secure and easier to use than passwords. Here's how we implemented them and why.

When we started building H1 Vault, one of the first decisions we made was to skip passwords entirely. No registration forms with password requirements, no "forgot password" flows, no credential databases to protect. Instead, we went all-in on magic links for admin users and email verification codes for buyers. Here's the reasoning behind that choice.

Passwords are a liability

Let's start with the uncomfortable truth: passwords are the weakest link in most applications' security. The data is clear on this. The majority of breaches involve compromised credentials. People reuse passwords across services, pick weak ones, and fall for phishing attacks that harvest them.

For a data room platform where the entire value proposition is security, storing passwords felt like a contradiction. Even properly hashed and salted, a password database is a target. If we don't have one, it can't be breached.

How magic links work

The flow is straightforward:

1

User enters their email

On the login page, the only field is an email address. No password field.

2

We send a one-time link

A unique, cryptographically random token is generated, stored with a 15-minute expiration, and emailed to the user.

3

User clicks the link

The link is verified against the stored token. If it matches and hasn't expired, a session is created.

4

Token is invalidated

Each token can only be used once. Even if someone intercepts the email later, the link is dead.

Buyer verification codes

For buyers accessing a data room, we use a slightly different approach: a six-digit verification code sent to their email. This works better for the buyer flow because buyers often access the data room from a link they received, and we need to verify that the person clicking the link controls the email address it was sent to.

The code expires after 10 minutes and is rate-limited to five attempts. After successful verification, the buyer receives a session token valid for 24 hours. The session persists across page reloads, so buyers don't have to re-verify every time they come back to the data room during a working session.

The security advantages

No password database to breach

We don't store passwords, so there's no credential database to steal. The most common attack vector against web applications simply doesn't exist.

Phishing resistance

There's no password to phish. Even if someone creates a fake login page, the worst they can capture is an email address, which isn't useful on its own.

No credential reuse

Since there's no password, users can't reuse a compromised password from another service. Each authentication is independent.

Time-limited tokens

Magic links expire in 15 minutes and verification codes in 10. The window for an attacker to use a stolen token is narrow.

The UX advantages

Security aside, passwordless auth is just a better experience. Our login page has a single field. Users don't need to think about password requirements, remember which password they used, or go through a reset flow. Click, check email, click again, done.

For buyers, this is especially important. Many buyers access a data room once or a few times over the course of weeks. Asking them to create an account with a password for a tool they'll use briefly is unnecessary friction. Email verification codes let them get in quickly with no registration required.

Trade-offs

Passwordless isn't perfect. It depends on the security of the user's email account. If someone's email is compromised, they're vulnerable. But this is true of password-based systems too, since nearly all of them offer "forgot password" via email, which makes email the ultimate fallback anyway.

There's also a slight friction cost: you have to switch to your email to get the link or code. In practice, most people have email open in another tab, so this takes a few seconds. It's a small trade-off for meaningfully better security.

Going passwordless was one of our earliest decisions and one we haven't second-guessed. It simplifies our codebase, reduces our attack surface, and makes the experience better for both admins and buyers. If you're building a product where security matters, it's worth considering.

Have questions about our security implementation? Reach out at our contact form.