Security

Crove tracks every sign-in attempt against your account so you can catch unfamiliar logins early. This page also covers the authentication options available and best practices for keeping your account safe.

Login history

Visit Settings → Security → Login history to see the last 100 sign-in attempts on your account.

Each row shows:

• ✓ green check or ✗ red X for success/failure
• The method icon (Magic link / Google / Password / Impersonation)
• IP address (when available — some sign-ins from the API don't carry one)
• User agent string (when available)
• Failure reason (for failed attempts only):
  • Email not found — typed an email Crove doesn't have an account for
  • Wrong password — credential mismatch
  • Server error — internal failure
• Relative timestamp (5 minutes ago, 2 days ago)

If you spot a sign-in you don't recognize, change your password immediately and notify your team admin.

What's NOT in login history

The page focuses on authentication events, not session activity. You won't see:

• API key calls (those are separately rate-limited and audit-logged by the public API surface)
• Impersonation activity by super-admins (those have their own audit trail and an in-app banner whenever active)
• Inside-the-app actions (those are in the per-document audit log, not the security login history)

Sign-in methods

Crove supports multiple sign-in methods. Use whichever fits your team's policy:

Magic link (default)

1. Enter your email on the sign-in page
2. Crove sends a one-time link valid for ~10 minutes
3. Click the link → you're signed in

Pros: no password to remember, no shared credentials.

Cons: requires email access; subject to email-delivery latency.

Google sign-in

If you signed up with Google or have linked Google to your account:

1. Click Continue with Google on the sign-in page
2. Google's consent screen
3. Redirected back, signed in

Pros: one-click; uses Google's 2FA if enabled there.

Password (optional)

If your workspace has password authentication enabled:

1. Set or reset your password from Settings → Account
2. Sign in with email + password from the sign-in page

Failed password attempts are logged with the reason (Wrong password, Email not found) so you can spot brute-force attempts in your login history.

Crove uses bcrypt for password hashing and never stores plaintext passwords.

Resetting your password

1. On the sign-in page, click Forgot password?
2. Enter your email
3. Crove sends a reset link valid for 1 hour
4. Click it, set a new password
5. Existing sessions remain valid (the reset doesn't kick you out elsewhere — change that with Sign out everywhere if you suspect a breach)

OTP verification (e-signing)

For high-trust signing flows, templates can require OTP verification before a respondent's signature is valid:

1. Respondent fills the form and clicks Sign
2. Crove emails (or texts, if SMS credits are configured) a 6-digit code
3. Respondent enters the code in the verification dialog
4. Signature is captured + timestamped + included in the audit PDF

OTP delivery is recorded in the document's audit trail with the respondent ID, channel (email / SMS), and timestamp — useful for compliance evidence beyond "they clicked the link".

OTP is configured per-template in People & roles → Signature settings.

Public fill bot protection

Every template's public fill link passes through two defenses before a document gets created:

• Honeypot field — the fill-landing page renders a hidden website input off-screen. No human ever fills it; most bots crawl the DOM and set every input they see. If the server receives a non-empty honeypot value the request is rejected with a silent 403 so the bot doesn't learn what triggered the reject.
• Per-IP rate limit — the public fill creation endpoint is gated at 30 requests per minute per client IP. Overflows return 429 with Retry-After / X-RateLimit-Reset headers so legitimate retries can back off cleanly.

Neither defense is user-visible for normal use, but if a template's link is getting abused the reject traffic shows up in the audit log with respondent.invited events noticeably absent despite visible load. Pair with a password gate or link expiry from the template's Link settings for compliance-grade forms.

Impersonation

Crove super-admins can impersonate users for support investigations. When an admin is impersonating you:

• A red Impersonation banner appears at the top of every page
• Every action they take is attributed to them in audit logs (not to you)
• A separate user_login_event row is created with method impersonation so you can see when it happened in your login history

Impersonation is an admin-only capability and is itself audit-logged on the admin side. If you see impersonation activity you didn't expect, contact support.

Account hardening checklist

For most users:

• Use Google sign-in OR a password unique to Crove (not reused from another service)
• If using password auth: enable 2FA on your email account (so a magic link can't be snatched)
• Periodically review Login history for unfamiliar IPs or methods
• Sign out from devices you no longer control
• Set notification preferences so you'd notice an unexpected document being signed under your account
• Don't share fill links — generate one respondent per person so audit trails stay clean

For workspace admins, additionally:

• Restrict who has the owner role (only people who should be able to delete the workspace)
• Use the admin role for trusted ops folks; user for everyone else
• Review Team management quarterly — remove people who have left
• Keep webhook signing secrets (whsec_…) in a secrets manager, not in repo configs
• Rotate API keys at least once a year, and on any offboarding