The security whitepaper for HuntingtonMod

1 — What we protect

The HuntingtonMod workspace holds ten small personal-utility apps — a personal journal, a daily expense tracker, a habit log, a mood weekly, a budget planner, a receipt scanner, a subscription tracker, a reading log, a gratitude notebook and a weekly review. The workspace never touches banking systems, never reads bank statements, and never holds funds. HuntingtonMod is not affiliated with, endorsed by or connected to Huntington Bancshares Incorporated, Huntington National Bank, or Huntington Investment Company. The security model described below is calibrated to protect the private notebooks that individuals confide to us, not to protect a bank.

2 — Trust boundary

The trust boundary of the HuntingtonMod workspace is the subscriber's dedicated bucket. Inside the bucket, only the subscriber and the on-duty incident-response engineer can read; outside the bucket, no one can. Every workspace has its own bucket; there is no shared table with cross-tenant rows. The bucket is provisioned at signup and destroyed at the end of the archive period.

3 — Encryption at rest

Every object stored inside a workspace bucket is encrypted at rest with AES-256 in GCM mode, using a per-workspace data-encryption key wrapped by a Hetzner-managed key-encryption key. Key material lives in HSM-backed key services in Frankfurt with hot-standby replication to Nuremberg. Backups are encrypted with a separate backup key that is never held on the production hosts.

4 — Encryption in transit

All traffic between the subscriber's browser and huntingtonmod.org is encrypted with TLS 1.3. TLS 1.2 with insecure suites is disabled at the load-balancer level. HSTS is enabled with a two-year max-age. Perfect forward secrecy is enforced. The certificate is issued by Let's Encrypt with a rotation window of 60 days. Internal service-to-service traffic between the application tier and the storage tier is encrypted with mTLS using SPIFFE-style identities.

5 — Magic-link authentication

There is no password. To sign in, the subscriber types their e-mail address; the server issues a single-use magic link, signed with an Ed25519 key that rotates every thirty (30) days, with a time-to-live of thirty (30) minutes. The link contains a random nonce and the timestamp; the nonce is invalidated at first use and at expiry. Repeated failed attempts trigger a two-minute cool-down per e-mail address; nine consecutive failed attempts lock the account and notify the subscriber by e-mail.

6 — Session handling

Once the magic link is redeemed, a session cookie ha_session is set. It is HttpOnly, Secure, SameSite=Lax, tied to the browser fingerprint at coarse granularity (accept-language + user-agent family), and destroyed on browser close. Sessions expire after twenty-four (24) hours of activity or ninety (90) minutes of inactivity. There is no persistent "remember me" option; the subscriber signs in again with a new magic link.

7 — Bucket isolation

Every workspace has its own storage bucket, provisioned by an automated pipeline at signup with a bucket-policy denying any subject other than the subscriber's session identity and the incident-response service account. Cross-tenant reads are impossible at the storage-service level — they cannot happen even if application code contains a bug, because the storage layer refuses the request. This is enforced through per-bucket IAM policies rather than through row-level security in a shared database.

8 — Application layer

The application is a small Go service running on Hetzner cloud servers in Frankfurt with hot-standby replication in Nuremberg. Content Security Policy is default-src 'self'; every response carries X-Frame-Options DENY and X-Content-Type-Options nosniff. Input validation happens with a strict schema at the edge; long-form text is stored as-is but sanitised at render with a whitelist of Markdown constructs.

9 — Two-person integrity control

Any privileged database action — read of a specific bucket by an operator, restoration of a workspace after cancellation, deletion of a workspace outside the automated pipeline — requires an approval from a second engineer, recorded in a signed audit log. There is no single-operator override; the on-duty incident-response engineer cannot self-approve.

10 — Backup schedule

Backups are full snapshots taken every four (4) hours, encrypted with a separate backup key, replicated to a third location within the EU, retained for thirty (30) days and destroyed by cryptographic key erasure at the end of the window. Monthly restore drills are run against a random sample of ten (10) workspaces to verify integrity end-to-end; the drill report is filed with the DPO.

11 — Vulnerability disclosure

We welcome coordinated disclosure. Please e-mail security@huntingtonmod.org with a description of the vulnerability, a proof of concept if applicable, and your preferred coordinated-disclosure timeline. We acknowledge within one working day and aim to fix critical issues within seven (7) days. Researchers who act in good faith may be published in the whitepaper appendix, with their consent, and receive a hand-written thank-you card from the Munich office.

12 — Incident response

Incidents are handled by an on-call rota of two engineers, with the managing director as the escalation contact. The playbook is: (1) detect — via monitoring alerts or human report; (2) contain — by revoking session tokens for the affected subset; (3) eradicate — by patching or rotating keys; (4) recover — by restoring from the previous good backup; (5) post-mortem — a blameless written summary shared with the DPO within seven days.

13 — Reportable-breach notification

In the event of a personal-data breach that meets the notification threshold of Article 33 GDPR, we notify the BayLDA within seventy-two (72) hours. Where Article 34 GDPR applies, we notify affected subscribers by e-mail without undue delay. Even in cases below the statutory threshold, we prefer to notify subscribers on a best-effort basis, in ordinary language, within seven (7) days.

14 — No US data transfer

Workspace content, backup content and metadata never leave the European Union. All sub-processors are EU-established; where a sub-processor operates a global network, the tenant we use is contractually pinned to an EU shard, verified quarterly by the DPO. There is no US-based key-management service, no US-based support console, and no US-based advertising platform. HuntingtonMod is not affiliated with, endorsed by or connected to Huntington Bancshares Incorporated, Huntington National Bank, or Huntington Investment Company; even in the absence of transfer risk, we would not share workspace content with those entities.

15 — Physical security

The Munich office keeps no production data on premises; laptops are full-disk-encrypted, remote wipe is enabled, and access to the office door is by physical key plus recorded log. The Frankfurt and Nuremberg data centres operate biometric + card double authentication with mantrap entry, 24-hour on-site guarding, and CCTV retained for thirty days.

16 — Supply-chain security

Every third-party library used in the application service is pinned to a specific SHA-256 checksum. Dependency updates are reviewed by two engineers before merge. Container base images are rebuilt weekly to pick up upstream security fixes. Build pipelines run inside a hermetic environment and produce reproducible artefacts.

17 — Penetration testing

We commission an annual external penetration test by an independent firm based in the EU. The most recent report (April 2026) closed with zero critical and two low-severity findings, both remediated within thirty days. A redacted executive summary is available to enterprise customers under NDA.

18 — Employee access

Three employees have privileged access to production infrastructure: the managing director, the head of engineering, and the on-duty incident-response engineer. Access requires a hardware security key (YubiKey 5C NFC) and an office VPN. Onboarding and offboarding processes are documented and rehearsed quarterly.

19 — Data minimisation

We deliberately do not collect data we do not need. There is no analytics tracking of individual users, no session replay, no fingerprint pixel, no third-party CDN of scripts, no external font provider. The site loads only its own resources from its own origin.

20 — Version history

v3.4 — 2026-08-01 — replaced Ed25519 rotation window from 60 to 30 days. v3.3 — 2026-05-14 — added quarterly EU-shard verification for Postmark and Fastmail. v3.2 — 2026-02-06 — moved backups to a third EU location. v3.1 — 2025-11-11 — introduced two-person integrity control on database actions. v3.0 — 2025-08-01 — original publication.

21 — Contact

For any security question, write to security@huntingtonmod.org or, for GDPR-specific matters, to dpo@huntingtonmod.org. Postal address: HuntingtonMod GmbH, Security Team, Maximilianstraße 34, 80539 München, Germany. HuntingtonMod is not affiliated with, endorsed by or connected to Huntington Bancshares Incorporated, Huntington National Bank, or Huntington Investment Company.