Chapter 15

Security and privacy

This chapter describes how the product protects the panel, the controllers and the data, and what the operator should do on their side. It is written so that an IT contact or a data-protection lead can read it without the rest of the manual.

Transport

• Web panel: the hosted service is served over HTTPS with automatically issued certificates (Let's Encrypt via the reverse proxy; chapter 16). A self-hosted panel also listens on HTTPS with a self-signed certificate on port 8443, because the Flash & adopt page needs a secure page to use the browser's serial and Bluetooth features. The panel honours the proxy's forwarded-protocol header so it knows it is being served securely.
• Controllers: talk MQTT to the panel's embedded broker on port 1883. The broker requires a username and password when ACS_DEVICE_USER and ACS_DEVICE_PASS are set on the server, which every internet-facing installation should do. Note that MQTT on 1883 is not encrypted: fob codes and door names cross the network in clear. The keyset is a list of fob codes and time windows, not names. Restrict port 1883 at the firewall to the site addresses that need it where you can (chapter 16). TLS MQTT is not offered by the current firmware.
• Firmware downloads for over-the-air updates are public files served without authentication (they contain no secrets). When a public HTTPS URL is set, controllers fetch them over TLS; the controller does not verify the certificate chain, which is the accepted trade-off for a device without a certificate store.
• Phone API: the PBX must use the HTTPS address; the bearer token and callers' numbers would otherwise travel in clear.

Accounts and sessions

• Passwords are stored as bcrypt hashes; the panel never stores or displays a password. Minimum length is 8 characters.
• Sign-in failures answer after a deliberate half-second delay, which blunts online guessing. There is no account lockout in the current release, so choose strong passwords and keep the number of admin accounts small.
• Sessions are random tokens stored hashed on the server, delivered in an HttpOnly, SameSite cookie, and expire after 7 days. Logging out destroys the session on the server. Deleting an account ends its sessions.
• Every form carries a per-session CSRF token; posts without it are refused.
• Roles are enforced on the server for every request, not just hidden in the interface: a viewer or a custom role that posts a change to a page it may not change gets "read-only account"; a page it may not view redirects.
• Super admin accounts are created only from the server console, never from the web.

Secrets held by the panel

Abuse protection on the phone API

• Wrong apartment PINs: after 5 consecutive failures the apartment is locked for 60 seconds, doubling per further failure to a cap of 16 minutes. A correct PIN during a lockout is still refused. The response carries a retry-after time.
• A PIN attempt for an apartment that does not exist takes the same time as a wrong PIN, so an attacker cannot enumerate apartment numbers by timing.
• Per-source-IP rate limit on all phone endpoints: a burst of 10, then about 2 requests per second.
• Every attempt, granted or refused, is logged with the caller ID as presented.
• Caller ID is not a secret; treat caller-ID release as convenience-grade (chapter 9).

Audit trail

The Log (chapter 11) records every access decision with the fob, person, door, time and reason; every door alert; and the system events that change who can get in (enrolment windows, imports, fob capture, controller registration). Log entries are never edited by the panel; deleting a tenant deletes its log.

Not recorded in the current release: panel sign-ins, and edits to people, levels or schedules as individual audit lines (their effect is visible in subsequent access decisions). Operators who need a change history should restrict edit rights to named accounts and keep periodic database backups.

Controllers

• A controller stores its Wi-Fi password, the panel address, the MQTT credentials and its keyset in its own flash. Anyone with physical access to the board and a USB cable can read the configuration (passwords are masked in the status query, but the flash itself is not encrypted) and could present a different keyset over USB. Mount controllers on the secure side of the door in a locked enclosure, never beside the reader.
• Reader lines (D0/D1) carry fob codes in clear; this is inherent to Wiegand and is true of every Wiegand system. Keep reader cabling inside the wall and use readers with tamper switches where the threat warrants it.
• Free egress: the exit button releases the door unconditionally by design.
• Firmware is updated only when an administrator presses Update; controllers do not fetch updates on their own.
• The watchdog restarts a stalled controller within 30 seconds; the keyset survives restarts and power cuts.

Data protection (UK GDPR / Data Protection Act)

The panel holds personal data. As the operator you are the controller of that data (in the legal sense); 2plus1 acts as processor where it hosts the panel. Points to cover in your records of processing:

• What is held: names, optional email and phone numbers, optional photographs, free-text notes, fob codes, apartment numbers, which doors a person may open and when, and a log of every door use with time and outcome. The lawful basis is normally the contract with the member or employee and the legitimate interest in securing the premises.
• Photos: are optional. Their purpose is identification at the reception screen. Tell people a photo will be taken and shown to reception staff; let them decline. Photos are stored in the database and served only to signed-in users of the tenant and to the reception screen link.
• Access log: reveals when individuals entered the premises. Decide a retention period that matches your purpose (many operators keep 3 to 12 months), and have the host trim older events (chapter 16). Restrict who can view the log with roles.
• Phone numbers: used only for caller-ID matching; the last nine digits are compared. Numbers of unrecognised callers to the access line are written to the log.
• Notes are free text; do not record special-category data (health, etc.) there.
• Subject access: a person's page and a filtered log export (chapter 16, database queries) give everything held about an individual.
• Erasure: moving a person to the trash suspends everything at once but keeps the record for 30 days; Delete permanently in the trash removes their record, photo and fobs immediately (chapter 6). Either way their historic log entries keep the name as recorded at the time. If full erasure is required, the host can anonymise those rows in the database. Note the 30-day trash window when answering an erasure request: use Delete permanently rather than waiting for the sweep.
• Reception screen: displays names and photos to anyone who can see the monitor. Position it so that the public cannot read it, and keep the link private.
• Room bookings and the resident portal (chapter 8) add: the resident's mobile number, their apartment number, what they booked and when, and any payment reference. Card payments are taken by Stripe, which holds the card details; the panel never sees or stores a card number. Login codes are texted through whatever SMS gateway the tenant configures, so that gateway is a processor of the resident's mobile number and should appear in your records.
• The public board at the portal address shows today's confirmed bookings by room and time with names reduced to initials, and needs no login. Anyone with the address can read it. Treat sharing that address as a publication decision, and simply do not share it if the building would rather not.
• Self-registration: an unrecognised mobile can create a person record with a name and apartment number from the portal. Those records are marked "Self-registered via the resident portal" and logged. Review them; they are the one route by which personal data enters the panel without a member of staff typing it.
• Multi-tenant hosting: each tenant's data is isolated at the application layer; all tenants share one database on one server operated by the provider.

Recommendations for operators

1. Use HTTPS only; never expose the plain HTTP port to the internet.
2. Set the controller MQTT credentials and firewall port 1883 to known site addresses.
3. Give each member of staff their own login with the least role needed; remove leavers promptly.
4. Regenerate the reception link and the phone token when staff or hardware leave.
5. Keep the enrolment-mode window short and staffed.
6. Mount controllers on the secure side in locked enclosures.
7. Back up the database (chapter 16) and test a restore.