Security
A shared login can't be made un-shareable. SplitASeat is built so that the account can always be taken back, every use is visible, and abuse costs the abuser their seat and their account.
Everything below rests on one idea: the pieces you need to recover an account — the mailbox, the 2FA secret and the ability to reset the password — stay with SplitASeat, never with a member.
The account password and the 2FA secret are encrypted with a key that exists only for that pool, itself wrapped by a master key that never leaves the server. Plaintext is never written to the database or to logs.
SplitASeat enrols authenticator-app 2FA and keeps the secret. When a provider asks for a code, your dashboard generates the current six digits for you. Nobody in the pool ever sees the secret that produces them.
Every shared account is registered to an address on SplitASeat's own mail domain. "Forgot password" always works for us, and members can read the provider's verification emails without touching the account settings.
Every password reveal, generated code and inbox view is recorded. Members see the pool's activity by seat number — "Seat 3 revealed the password" — never by name.
If the provider's own "password changed" email arrives — passing DMARC, from a sender domain we trust — the pool freezes automatically. We recover the account through the mailbox and 2FA we control, rotate the password and remove whoever did it.
We would rather you join knowing exactly what this does and doesn't protect against.
A member who already holds the password and can fetch a code can still change the password on the provider's site. The mailbox and the 2FA custody are what make that recoverable, not impossible.
What SplitASeat does is make the attempt pointless (we recover the account), visible (the audit log, authenticated security-alert detection and the freeze) and costly (identity through Stripe, removal from the pool and a ban).
Sharing accounts may violate a provider's terms of service. The operator of this site is responsible for the services it lists, and SplitASeat is not affiliated with any provider.
Three kinds of people touch a pool: members, support staff and admins. Support staff handle tickets, billing problems and account recovery, so they can see more than members — but never the password or the 2FA secret.
| What | Member | Support | Admin |
|---|---|---|---|
Account email address | Yes | Yes | Yes |
Account password Members and admins reveal it with a recent sign-in; every reveal is logged. Support never sees it. | Limited | No | Limited |
Current 2FA code Generated on demand and logged. Support needs it to recover accounts. | Yes | Yes | Yes |
2FA secret Only an admin can export it, with a reason, and the export is logged. | No | No | Limited |
Pool inbox: verified login codes Members lose access to codes received after a freeze. | Yes | Yes | Yes |
Pool inbox: all other mail, including its text and links | No | Yes | Yes |
Pool activity log Members see events by seat number; staff see who was behind each seat, plus IP and browser. | Limited | Yes | Yes |
Other members' names, emails and payments | No | Yes | Yes |
Revealing the password is a deliberate act. It requires that your session authenticated within the last 15 minutes; if it didn't, the dashboard asks you to confirm your password or sends a magic link before showing anything. The password stays on screen for 60 seconds and is never written into the page's URL or logs.
2FA codes are generated on the server from the vaulted secret. The dashboard refreshes the code as it expires while you have the panel open, and stops after ten minutes.
Each shared account is registered to its own address on SplitASeat's mail domain. Inbound mail is routed strictly by the address it was delivered to — not by whatever the message claims in its headers — and sorted into codes, security alerts, password resets, billing and other.
A message counts as verified only when it passes DMARC and comes from a sender domain listed for that service. Only verified messages get their code extracted or can trigger a freeze. Everything else is stored with an “Unverified sender” banner for staff and does nothing on its own.
HTML mail is sanitised before storage: images are stripped, links to hosts outside the provider's domains are removed, and staff see the result only inside a sandboxed frame with no scripts, no network access and no referrer. Plain text is shown by default.
Members only ever see verified login codes, never the text or links of an email, so nobody can use a link to change the account or move a household. Mail about those changes stays with staff. Codes are shared by every member with an active seat, so never use the shared account for anything personal.
When a verified critical alert arrives — password changed, email changed, two-factor changed, account recovery started — the pool freezes automatically: reveals and codes return a “pool frozen” error, and members can no longer see codes received after that moment. Warning-level alerts (new sign-in, unusual activity, “was this you?”) are logged and shown to staff without freezing anything.
Staff then use the mailbox and the 2FA they control to run the provider's recovery flow, set a new password, update the vault and remove and ban the member responsible. Everyone in the pool is emailed when it freezes and again when it is released.
After staff rotate a password themselves, auto-freeze is suppressed for 30 minutes so the provider's own “password changed” confirmation doesn't lock the pool. Alerts in that window are still logged.
Each pool gets its own random data key. The password and the 2FA secret are encrypted with that key using AES-256-GCM, with the pool's id and the field name bound into the ciphertext so a value can't be swapped between pools or fields. The data key is itself encrypted by a master key that lives only in the server's environment and can be rotated without re-entering any secret.
Plaintext secrets are decrypted only for the request that needs them and are never written to the database, to logs or into URLs. Members see the password for one reveal and the 2FA code, never the secret.
Staff accounts must verify a second factor before they can open the admin area. Admin actions that touch secrets — a password reveal, exporting a 2FA secret — require the same recent sign-in as a member reveal, require a written reason, and are logged with that reason, the staff member's identity, IP address and browser.
Support staff can see everything a member can for every pool, plus tickets, users and alerts. They cannot see passwords or 2FA secrets and cannot change credentials, freeze pools or remove members; those are admin actions.
An hourly housekeeping job enforces these windows automatically.
| Data | Kept for |
|---|---|
| Bodies of code, password-reset and security-alert emails | 24 hours, then blanked |
| All pool mail | 30 days, then deleted |
| IP address and browser on activity-log entries | 90 days, then blanked (the event itself stays) |
| Raw Stripe webhook payloads | 30 days, then blanked |
| Pool secrets | Until the operator rotates or closes the pool |
The privacy page covers what we keep about you as a person and how to delete your account.
If you think a shared account has been tampered with, or you've found a security issue in SplitASeat itself, open a support ticket from your dashboard or email support@splitaseat.com. Please don't include passwords or codes in the message; staff never need them from you.