Skip to content

Security

Security you can audit, not adjectives

No “bank-level security” here. This page lists the actual mechanisms protecting your family's data — written by the engineers who built them, including what we haven't built yet.

Child's device

Collects location & screen-time totals

only after visible consent

Encrypted in transit

All traffic uses HTTPS/TLS

nothing travels in plain text

Safentora API

Processes data to power safe-zone alerts*

credentials stored only as hashes

Your family only

Visible to guardians in your family group

never advertisers or brokers

*Safentora is not end-to-end encrypted: safe-zone alerts require our servers to compare locations against your zones. We say this plainly because you deserve the real architecture, not a buzzword.

The mechanisms

How your family's data is protected

Each card starts in plain language. Expand “under the hood” for the exact technical detail.

Passwords are never stored

We store a one-way scrambled version of your password. Even if someone stole our database, your actual password isn't in it.

Under the hood
Passwords are hashed with bcrypt (cost factor 12). Bcrypt is deliberately slow, which makes bulk guessing attacks impractical.

Sessions expire in minutes, not months

The credential your device actually uses is replaced every few minutes. A leaked one goes stale almost immediately.

Under the hood
Access tokens are JWTs with a 15-minute lifetime, signed HS256 with enforced issuer and audience claims. Long-lived refresh tokens are opaque random values, stored server-side only as SHA-256 hashes.

A stolen session locks itself out

Session credentials rotate on every renewal. If an old one is ever replayed — the signature of theft — every session on the account is revoked instantly.

Under the hood
Refresh-token rotation with reuse detection: presenting an already-rotated token revokes all of that user's refresh tokens, forcing re-authentication everywhere.

The browser never holds long-lived credentials

On the web dashboard, your session lives in a sealed cookie that page scripts cannot read — so even a malicious script couldn't steal it.

Under the hood
The dashboard uses a backend-for-frontend: tokens are held server-side in AES-256-GCM sealed httpOnly SameSite=Lax cookies. The only credential the browser ever sees is a single-purpose socket token that expires in 60 seconds.

Admin and family access can't cross wires

Platform-administration access is a separate system from family accounts — an admin credential is structurally useless on family data routes, and vice versa.

Under the hood
Two disjoint token families signed with different secrets and different audience claims (one for family sessions, one for the admin portal). Token rotation additionally asserts the role matches the portal on every renewal.

Child devices pair with a one-time code

You create your child's account, then connect their phone with a short-lived pairing code you generate. Each code works once and expires after 10 minutes.

Under the hood
8-character pairing codes (Crockford base32, ~40 bits) with a 10-minute TTL, stored only as SHA-256 hashes, redeemed atomically exactly once. Regenerating voids the previous code. Partner invites work the same way with a 72-hour expiry.

Brute force hits a wall

Repeated login or pairing attempts from one source are cut off quickly.

Under the hood
Per-IP rate limits: 20 login/registration attempts per 15 minutes; 10 pairing or invite attempts per 15 minutes; 10 admin login attempts per 15 minutes. Standard security headers (helmet) on every response.

Least privilege on the child's device

The powerful device permissions we use are scoped to the minimum: remote lock can lock the screen — and nothing else.

Under the hood
The Device Administrator enrollment requests only the force-lock policy (no wipe, no password reset). The accessibility service requests no window content. On-device tokens live in Android EncryptedSharedPreferences.

Honest limits

What we haven't built yet

Admitting gaps beats hiding them. This roadmap is public on purpose — hold us to it.

  • Two-factor authentication for guardian accountsplanned
  • Encryption at rest for the location databaseplanned
  • Independent third-party security auditplanned
  • Published transparency reports on a fixed cadenceplanned

Work with us

Found something? Tell us.

Good-faith security research helps every family using Safentora. We won't pursue action against researchers who report responsibly.

Report a vulnerability

Describe the issue, how to reproduce it, and its impact. Please don't access other families' data while demonstrating it.

security@scientistshublabs.dev

We acknowledge reports within 72 hours.

Report a security incident

Think your family's account was compromised? Contact us and revoke sessions from your dashboard — one password change signs out every device.

security@scientistshublabs.dev

Incident reports are prioritized same-day.

Want the everyday-language version? Read the privacy policy or visit the Trust Center.