Security, Privacy & Compliance

Overview

ThouShaltNotClick is a cybersecurity awareness and phishing simulation platform built for schools, dioceses, synagogues, mosques, and faith-based organizations of every tradition. We take the security of your community's data as seriously as we take the security training we provide. This document describes our security architecture, privacy practices, and regulatory compliance posture in technical detail.

We encourage IT directors, diocesan/congregational CIOs, and school administrators to review this document as part of their vendor due diligence process. If you have questions not covered here, contact us at security@thoushaltnotclick.com.

Encryption & Data Protection

Data in Transit

All data transmitted between your browser (or browser extension) and our servers is encrypted using TLS 1.3. We enforce HTTPS on all endpoints with HSTS headers. API communication uses certificate-pinned connections where supported.

Data at Rest

All data stored in our database is encrypted at rest using AES-256 encryption provided by our infrastructure provider (Supabase, hosted on AWS). Database backups are encrypted using the same standard.

Password Manager — Zero-Knowledge Encryption

Passwords stored in the ThouShaltNotClick Password Manager are encrypted client-side using AES-256-GCM (Galois/Counter Mode) inside your browser before they ever reach our servers. Your master password is never transmitted to us, never stored on our servers, and never appears in our logs.

Key Derivation — Argon2id (RFC 9106)

Your encryption key is derived from your master password using Argon2id — the password-hashing winner of the Password Hashing Competition and the modern standard recommended by OWASP, NIST, and the IETF (RFC 9106). Unlike older algorithms like PBKDF2, Argon2id is memory-hard, which means a brute-force attacker cannot speed up cracking with GPUs or custom ASIC hardware.

Our parameters: memory cost 46 MiB, time cost 3 iterations, parallelism 1, output 256 bits. These are above OWASP’s minimum recommendation (19 MiB, 2 iterations) and tuned for acceptable performance on entry-level Chromebooks while imposing a meaningful work factor on attackers. The KDF parameters are stored per-vault and protected by the envelope HMAC (described below) — meaning we can raise the work factor for new users in the future without breaking existing accounts.

Wrapped Vault Key Architecture

We use a standard “wrapped key” design: a per-user random 256-bit AES-GCM key encrypts every stored entry, and that vault key is itself encrypted with the password-derived Argon2id key. Changing your master password only re-wraps a single record (the vault key) instead of re-encrypting potentially hundreds of saved entries — this is the same architecture used by 1Password, Bitwarden, and Dashlane.

Envelope Integrity (HMAC-SHA256)

The wrapped vault key, salt, IV, and KDF parameters are all covered by an HMAC-SHA256 signature derived from your master password using a separate, domain-separated Argon2id derivation. This signature is verified on every unlock before we attempt decryption. If anyone — including a compromised TSNC server, a malicious database administrator, or an attacker with stolen credentials — modifies your envelope to attempt a downgrade attack, the HMAC verification fails and the unlock is refused. The server cannot forge a valid HMAC because doing so requires your master password, which we never have.

Database Segregation

Password vault data is stored in a dedicated, separate database from the rest of your account information. This limits blast radius: a SQL injection bug in our main application code cannot reach vault data, and a leaked credential for one database does not compromise the other. Even if both databases were compromised simultaneously, the attacker would see only AES-256-GCM ciphertext — your passwords would remain mathematically unreadable without your master password.

Per-Field Initialization Vectors

Every field of every saved entry (name, URL, username, password, notes) is encrypted with its own freshly random 12-byte initialization vector generated from the OS cryptographic RNG. AES-GCM nonce reuse is catastrophic; per-field randomness eliminates that risk entirely.

Platform Architecture

ThouShaltNotClick is built on a modern, security-first technology stack. All infrastructure components are hosted in the United States.

Access Control & Authentication

Role-Based Access Control (RBAC)

ThouShaltNotClick implements a strict role hierarchy with principle of least privilege. Each role can only access data within their organizational scope.

Multi-Factor Authentication (MFA)

ThouShaltNotClick supports TOTP-based MFA (compatible with Google Authenticator, Authy, Microsoft Authenticator, and any standards-compliant app). MFA can be required at the organization level for password vault access. Recovery codes are provided during MFA setup for account recovery.

Device Trust

When MFA is verified, users can optionally trust their device for 7 days. Trust is scoped to both the device fingerprint (browser characteristics) and network address (IP). Logging in from a new device or a different network always requires MFA verification, even within the 7-day window.

Impersonation Safeguards

Platform administrators can impersonate school accounts for support purposes. During impersonation, password vault access is completely blocked across all 32 vault API endpoints. Impersonation tokens cannot carry platform admin privileges. All impersonation sessions are logged with the admin's identity, the target user, timestamps, and IP addresses.

Rogue Admin Prevention (Multi-Admin Co-Approval)

For destructive or sensitive admin actions, ThouShaltNotClick requires independent sign-off from a second administrator at the affected organization before the action can proceed. This prevents a single elevated account from unilaterally extracting passwords or destroying data across organizations.

• Vault recovery: when a platform admin or enterprise admin initiates recovery of a departed user's vault, an admin from the target organization (or its parent enterprise, in the platform-admin case) must independently co-approve before the requesting admin can access the recovered passwords. The co-approval and the rationale are permanently recorded in the audit log.
• Vault wipe (reset): only an admin at the target user's own organization can wipe a vault. Platform admins and enterprise admins cannot directly destroy vault ciphertext from another org — they must coordinate with the org's principal or IT admin to perform the reset.
• Peer-reviewable activity log: every modifying admin action — staff deactivation, vault wipe, role changes, configuration updates — is recorded with a snapshot of the row state before the change. Any peer admin at the same organization can review recent activity and undo reversible actions. Self-undo is gated to encourage cross-admin review.
• Non-suppressible user notifications: every recovery event surfaces to the affected user via in-app notification AND personal email with full context, regardless of preferences.

The combination of multi-admin co-approval, a peer-reviewable action log, and user-visible notifications means that no single rogue admin — at any tier of the system — can quietly access or destroy another user's vault data.

FERPA Compliance

The Family Educational Rights and Privacy Act (FERPA) protects the privacy of student education records. ThouShaltNotClick is designed to operate as a "school official" with "legitimate educational interests" under FERPA.

How We Support FERPA Compliance

• We collect only the minimum data necessary to provide phishing simulation and security awareness training
• Student personally identifiable information (PII) is not required for platform operation — schools control what data they share
• All data access is controlled through RBAC with organization-scoped isolation
• Complete audit trail of all data access, modifications, and administrative actions
• Data export capability (FERPA-compliant format) for schools to fulfill parent/student access requests
• School offboarding process that permanently deletes all organizational data on request
• We do not sell, rent, or share student data with third parties for any purpose
• We do not use student data for advertising, marketing, or profiling

Data Retention

Phishing simulation data is retained for the duration of the school's active subscription plus 30 days. Upon subscription cancellation or school offboarding, all organizational data is permanently deleted within 30 days. Schools can request immediate deletion at any time.

COPPA Compliance

The Children's Online Privacy Protection Act (COPPA) governs the collection of personal information from children under 13. ThouShaltNotClick's phishing simulation platform is directed at school staff (adults), not students.

• The phishing simulation and training platform is used by school employees (teachers, administrators, staff) — not students
• The password manager is available to staff accounts only, not student accounts
• If student data is included in training scenarios (e.g., a simulated email referencing student names), schools control this content and obtain appropriate consent
• We do not knowingly collect personal information directly from children under 13
• Schools acting as educational agencies may provide consent on behalf of parents under COPPA's school consent mechanism

CIPA Compliance

The Children's Internet Protection Act (CIPA) requires schools receiving E-Rate funding to implement internet safety policies and content filters. ThouShaltNotClick supports CIPA compliance through cybersecurity awareness training that educates staff about online safety, phishing threats, and responsible internet use.

State Data Privacy Laws

Over 120 state laws protect student privacy beyond FERPA. ThouShaltNotClick's data minimization practices, transparent data handling, and strict purpose limitations are designed to satisfy the requirements of state laws including California's SOPIPA, New York's Education Law §2-d, and similar state-level student privacy statutes.

Schools with specific state compliance requirements should contact us for a tailored assessment.

Threat Intelligence & Email Analysis

Privacy-Preserving Analysis

When the browser extension analyzes an email for phishing indicators, the analysis happens locally in your browser. Email content is never sent to our servers unless the user explicitly opts in to AI-enhanced analysis. Even with AI analysis enabled, only metadata is transmitted — sender address, subject line, link domains, and a brief body preview (max 500 characters). Full email bodies are never stored.

External Threat Intelligence Sources

For enhanced threat detection, we query the following external services. Only sender domains, email addresses, and link URLs are sent — never email content.

Password Breach Monitoring

When checking passwords against the Have I Been Pwned database, we use the k-anonymity protocol. Only the first 5 characters of the SHA-1 hash of the password are sent. The full password hash — and certainly the password itself — never leaves your browser. This is the same privacy-preserving method used by 1Password, Firefox, and the NIST 800-63B guidelines.

Audit Logging

All security-sensitive actions are recorded in an immutable audit log with the following fields: actor identity, action type, affected resource, timestamp, IP address, and relevant metadata. Audit logs are available to organization administrators for compliance reporting.

Actions Logged

• All login attempts (success and failure), including MFA verification
• User account creation, modification, and deletion
• Role changes and permission modifications
• Phishing campaign creation, launch, and completion
• Password vault operations (create, share, recover — never the passwords themselves)
• External share approvals and denials
• Data export requests
• Organization onboarding and offboarding
• Administrative impersonation sessions
• browser extension installation and heartbeat events

Application Security

Input Validation & Injection Prevention

• All user inputs are validated and sanitized server-side
• HTML output is escaped using context-appropriate encoding to prevent XSS
• Database queries use parameterized statements (Supabase client) — no SQL injection vectors
• URL fetching for sandbox preview blocks private/internal IP addresses to prevent SSRF
• Webhook signatures are verified (Resend via Svix, Stripe via built-in verification)

Rate Limiting & Abuse Prevention

• Authentication endpoints: 10 requests per 15 minutes per IP
• Cloudflare Turnstile CAPTCHA on all public signup forms (6 endpoints)
• API rate limiting on all authenticated endpoints
• Phishing report abuse prevention: 3 point-earning reports per day per user, duplicate detection

Session Management

• JWT tokens with configurable expiration
• MFA tokens expire in 5 minutes
• Session invalidation on password change
• Impersonation tokens cannot carry admin privileges

Third-Party Services & Subprocessors

We use the following third-party services to operate our platform. Each has been evaluated for security practices and data handling.

Data We Collect & Why

Data We Do NOT Collect

• Student grades, test scores, or academic records
• Browsing history (the browser extension does not track browsing)
• Email content (analysis is local; only opt-in metadata is sent for AI analysis)
• Plaintext passwords (zero-knowledge encryption)
• Biometric data
• Social Security numbers or government IDs
• Health or medical information

Incident Response

In the event of a security incident involving unauthorized access to school data, we will notify affected schools within 72 hours of discovery, as required by most state breach notification laws. Our incident response process includes immediate containment, forensic investigation, regulatory notification (if applicable), and a detailed post-incident report shared with affected schools.

To report a security concern, contact security@thoushaltnotclick.com.

Certifications & Trust

SDPC NDPA Signatory

CSA STAR Registered

SOC 2 Type I

FERPA Compliant

BBB A+ Rating

NCEA Proud Partner

Active Certifications & Memberships

Certification Roadmap

All of our infrastructure providers — Supabase, Vercel, Railway, Stripe, and Resend — are independently SOC 2 Type II certified. Our application implements the same technical controls these audits evaluate: AES-256 encryption, role-based access control, multi-factor authentication, comprehensive audit logging, rate limiting, input validation, and incident response procedures.

We welcome schools and dioceses to conduct their own security assessment. Contact security@thoushaltnotclick.com to request a completed vendor security questionnaire or schedule a call with our team.

Questions & Contact

For security questions, vendor assessment requests, or compliance documentation, contact our security team at security@thoushaltnotclick.com. For data processing agreements (DPAs), contact legal@thoushaltnotclick.com.

We are happy to provide a completed vendor security questionnaire, sign your school or diocese's data processing agreement, or schedule a call with your IT team to discuss our security architecture.