01 Our Promise
Lab Nexa is built by LabNexa Technologies Sdn. Bhd. (Registration No. 060419020751), a small team in Malaysia. We are not a forty person security department, and we will not pretend otherwise. What we have instead is something simpler: we keep the system small, boring, and well checked, and we tell the truth when something goes wrong.
Our rule is this: collect as little as possible, protect what we keep as if it were our own (in a team our size, it literally is), and never ask you to trust us blindly. Everything below can be verified by asking us a direct question.
No system on the internet is unhackable. Anyone who tells you differently is selling you something.
What we can promise is this: we make attacks expensive, we notice when something looks wrong, and if we ever fail, you will hear it from us first, in plain language, with a plan.
bcrypt hashing
Passwords are stored as bcrypt hashes with per user salts. We cannot read your password, and we never will.
TLS everywhere
Every connection to Lab Nexa is encrypted in transit. No plain text traffic, ever.
30 day tokens
"Stay logged in" tokens are hashed, device bound, rotated on use, and die after 30 days.
36 month audit
Every privileged action is written to an audit log and kept for 36 months.
02 How We Protect You
Here is the actual list of attacks we defend against, and how, written the way we would explain it to a colleague, not to a regulator.
| The threat | What we actually do about it |
|---|---|
| Password theft | Passwords are hashed with bcrypt and a unique salt per user. The database contains hashes, not passwords. If our database leaked tomorrow, your password would still not be in it. |
| Session hijacking | Sessions ride on standard PHP session cookies. The optional "stay logged in" token is cryptographically random, hashed before storage, tied to your device fingerprint, rotated every use, and expires in 30 days. Stolen from another device, it is useless. |
| Forged form submissions (CSRF) | Every form carries a single use CSRF token. A submission without a valid token is rejected before any code runs. |
| Injected scripts (XSS) | Every value we render is escaped on output. Text you type into Lab Nexa is displayed as text, never executed as code. |
| SQL injection | Every database query in the codebase is a prepared statement with bound parameters. There are no string concatenated queries in our code. |
| Bots and spam | Public forms carry hidden honeypot fields that humans never fill, plus per IP rate limiting (one submission per few minutes). Bots trip both. |
| Unauthorized access | Role based access control is checked on every page and every action. A student's request for an admin page simply does not exist as far as the server is concerned. |
| Cross institution leaks | Every query is scoped by university and school. One institution's data is invisible to another, by construction, not by promise. |
| Eavesdropping | All traffic is served over HTTPS/TLS. |
| Data loss | Backups are taken regularly and retained up to 90 days. They exist for disaster recovery only. Nobody browses them. |
03 Product Security
Lab Nexa has a few features that deserve their own explanation, because they are the parts people rightly ask about.
NFC cards and taps
Your NFC card holds one thing: a random token. No name, no IC number, no personal data is written to the card. If someone cloned it, they would have a random string we can revoke in one click. NFC only works at a few centimetres, so drive by reading is not a realistic threat. If you lose a card, tell your supervisor and the token dies immediately.
One seat, one identity
A seat holds exactly one active session. If someone else taps the same PC, the previous session ends and the new one begins, and the ledger records who had the seat, and when. Nobody can quietly borrow someone else's attendance.
Force logout is recorded, not silent
When a lecturer or supervisor ends someone's session, the record says who ended it and why. Power that leaves a trace is power that can be questioned, which is exactly the point.
Guest access is short and sponsored
Guest sessions expire after 4 hours, carry limited permissions, and always have a named sponsor inside the institution who asked for them. When the window closes, access closes with it.
Bulk import, explained honestly
When a university imports hundreds of accounts from an Excel file, we validate the file type and required columns, process the rows, and discard the file. Because nobody can hand deliver 300 passwords, imported accounts start with the IC number as a temporary password, and the system forces a password change on first login. It is a convenience with a short fuse, and that is deliberate.
We record that a PC is in use. We do not monitor screens, read files, log keystrokes, inspect browser history, or listen to microphones. There is no agent on the lab PCs doing surveillance, because we never built one.
04 Who Can See What
Access follows responsibility. Here is the whole matrix. If someone can see something that is not on this table, that is a bug and we want to know about it.
| Role | Can see | Can do |
|---|---|---|
| Student | Own sessions, own complaints, live map of the lab they are currently in | Tap in/out, file and cancel complaints |
| Guest | Own guest session only, for 4 hours | Use the assigned PC during the visit |
| Lecturer | Sessions in labs during their active class | Open/close class, approve or deny complaints, end sessions in their class |
| Supervisor | Their assigned labs: PCs, tags, sessions, routed complaints | Manage PCs and tags, mark faults, resolve complaints |
| School Admin | All labs in their school: usage, complaints, analytics | Manage labs and supervisors, remind or escalate |
| University Admin | Everything inside their university: users, schools, tickets, reports | Create users and schools, bulk import, escalate to Platform |
| Platform Admin | All universities, platform audit logs, escalations | Platform configuration only, no lab level meddling |
Nobody, including us, browses individual session data out of curiosity. Access is scoped to a job, and every use of privileged access lands in the audit log.
05 Your Side of the Deal
Security is a two person job. Here is our half and yours, side by side.
| We do | You do |
|---|---|
| Hash and protect your password | Choose a password you do not use anywhere else, and never share it |
| Bind remember me tokens to your device | Do not tick "stay logged in" on shared lab PCs |
| Make NFC tokens revocable in one click | Report a lost card or phone straight away |
| Log out idle sessions and record force logouts | Tap out when you leave, so the seat frees for the next person |
| Watch audit logs for odd patterns | Tell us if something looks wrong, a strange login, a seat you did not use |
| Never email you asking for your password | Treat any such email as fraud, and forward it to us |
06 Where Data Lives
Your data is stored on servers operated by or on behalf of Lab Nexa, under our direct control. We use no third party processors, no cloud analytics, no data brokers. There is nobody else in the room.
We do not transfer personal data outside Malaysia except where the law requires it or you have asked us to. Retention periods (24 months for session logs, 36 months for audit logs, 90 days for backups, and the rest) are listed in full in our Privacy Policy. We will not repeat them here and risk the two documents drifting apart.
We do not sell or rent personal data, and our agreements with institutions prohibit them from doing the same. If Lab Nexa ever changes hands, this policy travels with your data.
07 Logs and Audit
We log the things that matter for accountability, and we are deliberate about what we do not log.
What we log
- Logins and failed login attempts
- Password changes and permission changes
- Session starts, ends, and force logouts (with who and why)
- Complaint decisions: approvals, denials, cancellations, escalations
- Bulk imports and account creation by administrators
What we do not log
- Screen content, files, keystrokes, or browsing activity
- The content of your messages beyond what you submit into a form
- Anything about you from other institutions' systems
Audit logs are kept for 36 months and are readable only by University and Platform Admins. And the act of reading is itself the kind of thing people get asked about.
08 When Things Go Wrong
This is the part most policies skip. Here is exactly what happens if Lab Nexa is ever breached.
- First hours: contain. Affected sessions and tokens are invalidated, secrets rotated, and the hole closed or the affected component taken offline.
- First day: assess. We establish what was touched, whose data, and how far it went. Evidence is preserved, not deleted.
- Within 72 hours: tell you. Affected users and their institution receive a plain language notice: what happened, what was exposed, what we have done, and what you should do (usually: change your password, which we will force anyway).
- Afterwards: fix and publish. We patch the root cause, review how it happened, and publish a summary when publishing does not create a new risk.
Where Malaysian law requires notifying the Personal Data Protection Commissioner of a breach, we comply, on time, not reluctantly.
From us, directly, at the email on your account and through your institution's admin. Never from a journalist first. If you ever learn about a Lab Nexa incident from the news before hearing from us, we have failed at something more important than the breach.
09 Reporting a Vulnerability
If you find a hole in Lab Nexa, we want to hear from you, including if you are a student who stumbled onto it at 2am. Researchers make the whole ecosystem safer, and we treat them that way.
How to report
Email labnexatechnology@gmail.com with the subject line Security disclosure. Include what you found, how to reproduce it, and which accounts or data were touched in your testing. Please give us a chance to fix it before public disclosure. 90 days is the customary window and we will usually be much faster.
What we promise researchers
- An acknowledgement within 2 business days, from a human.
- No legal action and no complaints to your institution for good faith research.
- Regular updates while we fix it, and a note when it ships.
- Credit in our release notes if you want it, and anonymity if you do not.
We are a small team and we do not run a paid bug bounty programme yet. We would rather say that plainly than dangle a reward we cannot honour. What we can offer is a fast, friendly response and a genuine thank you. When the company grows, bounties are on the list.
Out of scope
- Social engineering of staff or students
- Physical access to labs or hardware
- Denial of service testing or spam campaigns
- Scanning or testing services we do not operate
- Disclosing another user's data beyond what is needed to prove the issue
10 What We Will Never Do
A security policy should tell you what a company will not do. Here is ours, in full:
- Sell or rent your data. Not now, not ever, not "anonymized" versions of it.
- Add advertising or third party trackers to any Lab Nexa page.
- Watch your screen, read your files, log your keystrokes, or inspect your browsing.
- Email you asking for your password. Anyone who does is not us. Report it.
- Keep your data longer than we need it. Retention has deadlines, and we honour them.
- Use dark patterns to keep you signed in, subscribed, or stuck.
- Share guest data beyond the single visit it was collected for.
- Change this policy silently. Material changes get a new date, a notice, and where required, your consent again.
11 Security FAQ
No. It is stored as a bcrypt hash with a unique salt. We could not read it if we wanted to, and we would refuse even if we could. If anyone ever emails you asking for your password, it is not us.
No. NFC works at a few centimetres. And even a cloned card would only carry a random token that your supervisor can revoke in one click. The card never holds your name or IC number.
Honestly: do not use it on shared machines. The token is hashed and bound to the device, which makes it safe on your phone or laptop. But a shared PC means the next person sits at the same device. On lab PCs, log out when you leave.
Because nobody can hand deliver 300 passwords on day one. It is a temporary convenience with a short fuse: the system forces a password change at first login, and the temporary password is only ever as secret as your IC number already is.
We run regular internal security reviews and act on our own disclosure programme. Independent third party penetration testing is on our roadmap as we grow. We would rather tell you that plainly than claim a certificate we do not have.
Contain within hours, assess within a day, notify affected users and their institution within 72 hours in plain language, then fix the root cause and publish a summary. Where Malaysian law requires notifying the regulator, we do. Full detail in section 08.
Not yet. It is on our roadmap. Until then we compensate with strong password hashing, device bound sessions, rate limiting, and audit logging. If your institution requires 2FA contractually, talk to us. It is one of the first things we will build next.
No. Good faith research gets an acknowledgement within 2 business days, no legal action, updates while we fix, and credit if you want it. See section 09 for scope and how to report.
12 Changes and Contact
When we change how we secure your data, this page changes with it: a new "Last Updated" date at the top, a notice in app for material changes, and fresh consent where the law asks for it. Continued use after a change means you accept it.
Questions, concerns, or a vulnerability to report? One email reaches a human who builds this system:
Security Contact
LabNexa Technologies Sdn. Bhd. · Registration No. 060419020751 · Registered in Malaysia (operated remotely)
Security disclosures are acknowledged within 2 business days. Everything else, within 30 days at the outside.