Administrator information and participant rosters entrusted by organizations are organizational assets. YouthOn stores this data on a separate security server isolated from service servers and protects it using the strongest encryption currently practical to implement.
A diagram of the security layers: transit, access, storage, review, and items not yet in place
Data in Transit — Every Connection
Every path between browser and server and between servers is encrypted. There is no plaintext communication path.
ProtocolTLS 1.3 only · legacy versions and weak cipher suites are disabled entirely
Cipher suitesAES-256-GCM or ChaCha20-Poly1305
Key exchangeECDHE -based Perfect Forward Secrecy (PFS) — a new session key is created for every connection and destroyed when the session ends. Even if a server key is compromised later, past traffic cannot be decrypted.
Between serversMutual TLS (mTLS) — both sides must verify each other's certificate before a connection is allowed
Data at Rest — Stored Data
Different data uses different encryption keys. Compromise of one does not expose the others.
Content encryptionAES-256-GCM envelope encryption — a separate data encryption key (DEK) is generated for each record
Key protectionData keys are wrapped again with a key-encryption key (KEK), and the master key exists only inside an HSM(hardware security module). The key itself cannot be extracted.
Key rotationMaster keys are rotated automatically on a regular schedule, and a new data key is generated each time. Encrypting the same value twice produces a different result every time.
PasswordsArgon2id one-way hash — the original password cannot be recovered from the stored value
SearchBlind index (HMAC-SHA-256) — query data without storing plaintext
BackupsBackups are encrypted the same way and their keys are stored separately
Network Isolation — Separate Security Server
Personal information is not stored on internet-facing service servers. It is stored only on a separate server that cannot be reached directly from the internet.
LocationA private-only network with no public IP — there is no external connection path at all
InboundOnly preregistered services that prove identity with an mTLS certificate can connect
OutboundDefault deny — it cannot communicate with any server not on the allowlist. This blocks data-exfiltration paths at the source.
PermissionsEach service account receives only the minimum required permissions · fields outside the required scope cannot be queried
Administrator accessOnly through a management path protected by fixed IP and multi-factor authentication · every session is recorded and logged
Auditing and Anomaly Detection
We record who viewed what and when, and when unusual activity appears, the system stops it before a person needs to intervene.
Access logsEvery view · edit · download is logged and sealed with a hash chain so records are tamper-proof.
Regular reviewsIncluding authenticated in-house platforms, all access logs are reviewed periodically.
Bulk accessIf views · edits · downloads exceed a defined threshold, access is blocked automatically and immediately, and the administrator is alerted
Anomalous patternsSessions are terminated when access occurs at unusual times, locations, or speeds
RetentionAccess logs are kept for at least the statutory period and duplicated in separate storage
Even YouthOn's Operators Cannot Read the Content
We believe the right approach is not “trust us,” but designing the system so we structurally cannot see it . Decryption keys never leave the HSM, and operator accounts do not have decryption permission at all. Even opening the entire database reveals only meaningless ciphertext.
Keys are not in human handsMaster keys are used only inside the HSM and cannot be exported. Operators cannot see the key values.
Values are constantly renewedSession keys change per connection, data keys per record, and master keys on a regular schedule. Even if one value is learned at a point in time, it cannot be reused moments later.
No one person can decrypt itIf decryption is unavoidably required, approval from at least two people is needed, the action is logged, and the organization is notified.
Operators still see masked dataEven for support purposes, personal information is displayed masked. Viewing full values requires a separate approval process.
About the implementation timeline
The above describes YouthOn's security design and operating standards. Applications, inquiries, quotations and orders are currently stored on Cloudflare servers (a D1 database and private R2 storage), encrypted in transit with TLS and at rest by default. Sign-in uses a password by default with one-time email links as an alternative; passwords are stored as irreversible hashes (PBKDF2-SHA-256, 100,000 iterations), and link and session values are stored only as hashes. Administrator accounts require a second factor from an authenticator app. Items above that are not yet in place, such as HSM-based envelope encryption and network separation, are being rolled out in stages, and we will publish configuration details and audit results on this page as each one is applied. Actual processing items and retention periods are described in the Privacy Policy.
Found a vulnerability?
Report it and we will investigate, fix it, and tell you what we did.
How to report
Email hello@youthon.kr with [SECURITY] in the subject line and we will
prioritise it. If email is inconvenient, use the contact form
and pick the Security vulnerability report topic.
Reproduction steps, the affected scope, and the date you observed it help us move
faster. Screenshots or request/response logs are welcome.
What happens next
AcknowledgementWithin 3 business days
InvestigationWe reproduce it and assess the impact
FixPrioritised by severity
Follow-upWe tell you what changed and when
Please do not
Access or download other customers' real data
Delete or modify data
Run denial-of-service tests or large automated scans
Use phishing or social engineering against staff or customers, or attempt physical access
If you need to verify something, ask us and we will set up a test account.
For reporters
We will not pursue legal action for good-faith reports that follow the rules
above. Please give us time to fix the issue before disclosing it publicly.
We do not run a paid bounty programme at this time. If you would like, we will
credit your name or handle on this page once the fix ships.