EduBoardSecurity overview
For a school's IT or data protection review · 28 September 2026
In short
- The teacher's app keeps student data on the teacher's computer, not in a cloud. It can encrypt everything and lock itself.
- The Portal holds only what the teacher publishes and what families add. It uses HTTPS only, hashed passwords, rate limits, and checks on every request that a family sees only their own children.
- What isn't done yet is listed at the end: no code signing, no independent audit or certification, and no two-step sign-in so far.
1. The teacher's app
| Where data lives | A database file on the teacher's computer, and backups the teacher makes. There is no EduBoard account and no cloud copy. |
|---|---|
| Encryption | With password protection on, the database and its backups are encrypted with a random 256-bit key (ChaCha20-Poly1305, SQLite3 Multiple Ciphers). That key is stored only encrypted (AES-256-GCM) under the teacher's password and under a recovery key, each stretched with scrypt; it is never stored in plain form. |
| Locking | With password protection on, a lock screen at start and automatic locking after a set idle time (10 minutes unless the teacher changes it). Presenting mode shows only class screens and hides pages with private details while the screen is shown to a class. |
| Record of changes | Every grade, attendance, enrolment and homework change is logged with when it happened. A removed student's entries are kept for 12 months, then deleted. A student can be erased completely, including from the Portal. |
| Network | Only what the teacher sets up: publishing to the Portal (HTTPS), AI suggestions with the teacher's own key (sent only when the teacher asks), DingTalk or WeCom group posts, update checks, and an anonymous weekly count that is off unless turned on. Exit tickets stay on the classroom Wi-Fi. Files downloaded from the Portal are marked as coming from the internet, so the operating system checks them. |
| Updates | From EduBoard's GitHub releases over HTTPS (relayed by the Portal where GitHub is blocked), with the file size checked. A backup is made before an update installs. |
2. The Portal
| Connections | HTTPS only, with certificates from Let's Encrypt (Caddy). Browsers are told to use HTTPS for the site from then on (HSTS). |
|---|---|
| Passwords | At least 8 characters, stored only as bcrypt hashes. A family changes their own password with the current one; a forgotten one is reset by the teacher, which signs the account out everywhere. |
| Sessions | A signed cookie that scripts can't read (HttpOnly, Secure, SameSite=Lax), valid for 30 days, cancelled everywhere when the password changes or is reset. |
| Who sees what | Checked on every request: a family sees only the children linked to their login, and only those children's classes. Each teacher publishes with their own sync secret and sees only their own classes. Sync and admin secrets are stored only as hashes, and a teacher's secret is shown once, when it's made. |
| Guessing and flooding | Limits on sign-in attempts per address (50 in 15 minutes) and per username (10 failures in 15 minutes), on invite and QR links, on wrong secrets, on password changes and on AI use. Request sizes are limited before anything is read. |
| Uploaded files | Checked by their contents, not their names: programs and Office documents with macros are refused, and only expected types are accepted (PDF, Office, images, text). Size limits: 20 MB for handed-in work, 25 MB for teachers' attachments, 10 MB for a report card. |
| Pages | Nothing is loaded from other websites: no analytics, advertising, outside scripts or fonts. Pages can't be framed by other sites, links don't leak addresses (no referrer), and errors never show internal details, only a code and a reference. |
| AI keys | The teacher's AI key for the Study Helper and translation stays on the server and is never sent to a browser. |
| Demo login | The public demo (username demo) sees only a made-up class under its own teacher, and its password, email and QR logins can't be changed. |
3. Running portal.edu-board.com
- A server in Hong Kong (VPS.do). Only the Provider can sign in to it.
- A firewall lets in only the website and the Provider's sign-in; addresses that keep failing to sign in are blocked. Security updates install automatically.
- The Portal runs as its own restricted user, which can change only its own data folder, not the rest of the server.
- The packages EduBoard is built on are checked for known security problems on every change and every week, and updated when a fix is published.
- Updates are applied with a script that backs up the data first. Backups are kept on the same server; the oldest is deleted once there are 14.
- If something goes wrong with a school's data, the school is told within 48 hours of the Provider finding out (see the data processing terms).
- A school can run the Portal on its own server instead (it's open source), and then controls all of this itself, including where backups go.
4. Not done yet
- Code signing. The Windows installer isn't signed yet, so Windows shows a warning the first time.
- Independent review. No outside security audit or penetration test, and no certification (ISO 27001, SOC 2, or China's MLPS 等保) yet.
- Two-step sign-in for the Portal.
- Off-site backups for portal.edu-board.com: backups are on the same server for now.
- EduBoard is made by one developer; there is no security team or on-call rota.
5. Reporting a problem
If you find a security problem, write to privacy@edu-board.com, or report it privately on GitHub, with what you found and how to see it. Please don't test against other people's accounts or data. You'll get an answer, and a fix as soon as it can be made.