AlumDeck
Live demo

Run · Security & access

Two-factor sign-in, and a log of who did what.

Your alumni data sits in your own database. The admin panel adds two-factor sign-in, sessions that end themselves, permissions by committee area and an audit log of who did what.

Open the demo admin sign-inRead the security overview
  • 60idle minutes, then signed out
  • 12hours, the longest admin session
  • 13permission areas
  • 365days of audit log

How it works

Four controls a committee can actually check.

Each one is in the demo. Sign in as the administrator and look.

Two-factor

Two-factor sign-in for admins

Required for everyone with admin access. Each admin chooses an authenticator app (scan a QR code or type the key) or a code sent by email. Setting it up needs an emailed code first. Eight wrong codes lock the account for 15 minutes; the lockout is recorded and the administrators are told.

  • Any authenticator app, no extra service
  • Compulsory once the site can send email
  • A server command switches it off for a locked-out admin

Sessions

Sessions that end themselves

An admin session ends after 60 idle minutes (the page checking in the background does not count), and after 12 hours whatever happens. There is no "remember me" for admins, and a session only works in the browser that started it.

  • Session ID changed every 30 minutes
  • A new IP address is recorded, not blocked
  • Five admin sign-in attempts a minute

Permissions

Permissions by committee area

Thirteen areas, each given at view, edit or manage level. A person with none cannot enter the panel. Staff cannot make themselves full administrators or grant the users area, and settings, backups, member import and menus stay with full administrators.

  • The events volunteer sees events, nothing else
  • No self-promotion
  • Settings stay with full administrators
Read about the admin panel

Audit log

An audit log of who did what

Sign-ins, sign-outs and failed sign-ins (with the email masked), ended sessions, two-factor events, imports, tracking-code changes, bulk changes, and every create, edit and delete on members, users, money, content and settings. Each line has the person, the time and the IP address.

  • Read-only in the admin: nobody can edit or delete a line
  • Old and new values for member and user profile fields
  • Kept 365 days, then pruned monthly

Beyond the admin

The quiet protections, on by default.

What else protects your members
What it protectsHow
Join, contact, sign-in and password formsCloudflare Turnstile, once you add its keys in Settings, Security. The join, contact and member sign-in forms also carry a hidden honeypot field
Every form that saves somethingA rate limit per route: member sign-in 8 a minute, join 10 an hour, uploads 10 an hour
PasswordsAt least 12 characters for every account, and the current one is needed to change it
Member sign-inA password or a link by email, or the account a member already has: the one your institution gives them, or Google, Microsoft, LinkedIn, Facebook or Apple. Each of those accounts is off until you set it up. How members sign in
Text written by adminsCleaned every time it is shown, so even a stolen admin account cannot plant a script on public pages
CSV exportsCells that start like a spreadsheet formula are neutralised
Private filesDocuments, contact attachments and import files are handed out only after a permission check
Stored secretsThe SMTP password, two-factor secrets, provider keys and the backup passphrase are encrypted with your app key
Scripts and stylesA Content-Security-Policy with a new nonce on every page. On the public site and in the member area it carries no unsafe-inline and no unsafe-eval for scripts, and no inline styles except on a page that shows an email as it was sent. The admin panel keeps four documented exceptions its framework needs: unsafe-eval for scripts, inline styles, images from any https address, and blob addresses for upload previews
Every responsenosniff, frame and referrer policies, HSTS over HTTPS, and noindex on the admin, at whatever address you moved it to
The headers that really arrive"Check my headers", on Settings, Security and on Settings, SEO, fetches your home page and one of its files the way a visitor's browser does. It lists whether the Content-Security-Policy is AlumDeck's own, whether a tag or embed you switched on would be blocked by it, and which security headers something in front of AlumDeck, such as your host or a CDN, removed or changed. It only ever fetches your own site

Member sign-in

How members sign in, and what is checked each time.

A password and an emailed link are on from the start. The other two wait for you to set them up.

Password or emailed link

A password of 12 characters, or a link by email

A password is at least 12 characters, for every account and wherever it is chosen. A member who would rather not remember one types their address on the sign-in page and gets a link by email. The link works once, for 15 minutes unless you change that, and only in the browser that asked for it unless you switch that check off. The page says the same thing whatever address is typed, so nobody learns who is a member.

  • The link opens a confirm page first, so a mail scanner cannot use it up
  • Three links to one address in 15 minutes, then no more
  • Not offered to people with admin access, unless you allow it

Single sign-on

The account your institution already gives them

Switch on single sign-on and add your institution's provider over SAML 2.0, OpenID Connect or CAS 3.0. A sign-in reaches a member through a link made before, or else by a member or roll number or a verified email address from the domains you list; you decide whether anyone else becomes a new member. Every answer from the provider is checked in full: its signature against the certificate or key you configured, who it is for, its time window, and that it has not been used before.

  • Every sign-in, link and refusal is in the audit log
  • Staff accounts are never linked or created automatically
  • Members link and unlink a provider under Sign-in methods

Social sign-in

Google, Microsoft, LinkedIn, Facebook or Apple, through your own app

Switch on social sign-in, register your own app with each provider you want, and its button appears on the member sign-in page. No third party sits between your members and your site. Nobody gets a new account this way: the first time, the provider must confirm an address that belongs to an active member. The two are then linked, and the member is emailed.

  • Only the provider's id for the person and the address are kept: no passwords, no tokens
  • A member's own password keeps working either way
  • Facebook does not say whether an address is verified, so members link it from their profile first

Not yet

What security does not do yet.

A tag means a fix is planned. No tag means it is not.

  • Two-factor sign-in for members (admins only)
  • An independent penetration test: none has been done. Security is tested in-house and the results are published
  • A strict Content-Security-Policy in the admin panel: it still allows unsafe-eval and inline styles there, which its framework needs
  • Old and new values in the audit log for every record: they are kept for member and user profile fields, and other records keep the names of the fields that changed
  • LDAP sign-in: an institution's accounts connect through SAML 2.0, OpenID Connect or CAS 3.0
  • robots.txt naming a custom admin address: it lists only /admin, and the noindex header covers the address you chose
Everything AlumDeck does not doThe public roadmap

FAQ

Questions committees ask

Is two-factor sign-in compulsory for admins?

Yes. Everyone with admin access has to set it up, with an authenticator app or a code sent by email, before any admin screen opens. Setting it up needs an emailed code, so a new site starts asking as soon as it can send email.

Members cannot use two-factor sign-in. A site can lift the rule for its admins with REQUIRE_ADMIN_2FA=false in the .env file; the installer writes true.

Where is our alumni data stored?

In your own MySQL or MariaDB database and on your own hosting, in whatever country your host is in. We, the makers of AlumDeck, never receive your member data.

What does AlumDeck send back to its makers?

A licence check about twice a day, carrying your licence key, your site's address and a one-time random number, and nothing about your members. Our licence server sends back a signed answer. If you switch on the check for new versions, it also sends your version number.

If the licence has lapsed, been withdrawn or moved to another site, or your site has had no genuine answer for 60 days, admins see a banner. 21 days later, member and admin sign-in pause until it is put right. A new install that has never had an answer pauses sign-in 21 days after it was installed. The public pages stay up, and nothing is deleted.

Can we see who changed a member record?

Yes. The audit log shows who changed it, when, from which IP address, and which fields changed. For member and user profile fields it also keeps the old and new values; for other records it keeps the names of the fields that changed.

Has AlumDeck had an independent security audit?

No. No independent penetration test has been done. Security is tested in-house, and the results are published on the security tests page: OWASP ZAP (as a visitor, a member, an admin and an API client) against a local copy, Semgrep, dependency audits, a secret scan, a header check, the automated test suite, and code reviews by AI reviewers (Claude) directed by Cerevonix.

Try the admin sign-in in the demo.

Sign in as the administrator, open your profile and set up two-factor sign-in with any authenticator app.

Open the live demoPricing - $49 a year

Sign-in details on the demo pageResets every night

Type a word, or start with one of these pages.

↑ ↓ moveEnter openEsc close