Green Dot security whitepaper
This document describes how the GreenDotPlay account system is secured — the choices, the trade-offs and the boundaries. Written for players who care and for the occasional security-team visitor.
The sign-in flow
Green Dot accounts are passwordless. The only way in is a magic link emailed to the address registered on the account. This is a deliberate design: it removes the entire class of attack that starts with a stolen password. A leak of our database — even in the worst case — cannot expose credentials that can be replayed elsewhere, because we do not store password hashes at all.
Magic-link tokens are ES256-signed compact JWTs, valid for fifteen minutes, single-use enforced by a Redis set. Details in the magic-link token format doc.
Session cookies
After a successful magic-link redemption, a signed gd_session cookie is issued. It is HttpOnly, Secure, SameSite=Lax, first-party, with an absolute ninety-day expiry. Full details in session tokens and the Green Dot API.
Two-factor authentication
Optional email-code 2FA on top of the magic link. Six-digit code, ten-minute validity, required on every sign-in from a new device. See the 2FA guide.
Encryption
All traffic is HTTPS-only (HSTS, includeSubDomains, preload). Database encryption at rest uses AES-256 on the cloud provider's managed key. Backup encryption uses per-backup keys rotated monthly.
Access control on our side
Three humans currently have production access at GreenDotPlay: the CTO, the on-call engineer of the week, and the DPO for GDPR erasure execution. Every production login is logged; access is time-boxed to a two-hour window and expires automatically.
Incident response
Any credential-related incident is disclosed to the affected accounts within 48 hours by email and posted to /changelog. Regulator notification (AZLP) within 72 hours where the incident meets the GDPR threshold.