Security fact sheet
Download this fact sheet as PDF
In short
- Parish data lives in the parish's own datafile, on the parish's own computer. Nothing is sent anywhere unless the parish chooses to use the optional online Workspace.
- Everything travelling between the program, a browser or a phone and parishrecordkeeper.com goes over an encrypted connection (HTTPS).
- Every parish file kept on the server is stored encrypted (AES-256-GCM), with a separate key for each parish.
- Not encrypted unless you act: the datafile on your computer (set a database password), the copy on a phone (use the phone's screen lock), and any export you make.
1. On the parish computer
| What | Encrypted? | How / notes |
|---|---|---|
| The datafile (.PRK) | Optional | One click in the program sets a database password. The whole file is then encrypted by Microsoft Access's own database encryption (AES) and cannot be opened on another computer without the password. Without a password the file is readable by anyone who has a copy of it. |
| Copies of the datafile (backups, the dated copies kept before a replace, the sync base copy) | Same as the datafile | They are copies of the file, so they carry its password protection – or its lack of one. |
| The database password, remembered on this computer | Obscured only | Kept in the Windows registry of the user account, scrambled but not strongly encrypted, so the program opens without asking each time. The password protects a file that is copied or stolen; it does not protect a computer that is left switched on and signed in. |
| Server sign-in remembered for a datafile | Obscured only | Scrambled with a fingerprint of the computer, in the program's System folder. |
| Program PIN | – | An access lock for shared office computers, not encryption. |
| Exports (text, Excel/CSV, SQLite/MySQL, change files, printed reports and PDFs), log files and the program's working files | No | Plain files. Delete exports when they are no longer needed. |
2. On the way
| What | Encrypted? | How / notes |
|---|---|---|
| Program ↔ server, browser ↔ website, phone ↔ website | Yes | HTTPS (TLS). The website refuses plain http and tells browsers to use HTTPS only (HSTS). The program's server address is fixed to https://parishrecordkeeper.com. |
| Uploads and downloads of datafiles | Yes | Sent in 1 MB pieces over HTTPS. The password is checked once at the start; the pieces carry a one-time token instead. The server uses a file only after its size and SHA-256 fingerprint match what the program sent. |
| E-mails from the website (codes, notices) | In transit | Sent through an authenticated mail server over an encrypted connection. They never contain parish records. |
3. On the server (only when the parish uses a Workspace)
| What | Encrypted? | How / notes |
|---|---|---|
| The parish data on the server, the security copies of datafiles and their earlier versions, versions sent by members, the copies for comparing, change notes from computers and phones, the live sync log | Yes | AES-256-GCM, authenticated encryption: a file that has been altered, swapped or cut short is refused, not read. Each parish (and each diocesan store) has its own random data key. Those keys are themselves encrypted by a master key that is kept in a file outside the website folder and outside the database. A copy of the stored files, a backup of them or a dump of the database is unreadable on its own. |
| The online search copy (what the search pages, phones and shared reports read) | Yes | |
| Parish archive documents (minutes, pictures) | Yes | |
| Copies sent to the diocese, packages sent to the developer for support, upload pieces and download caches | Yes | |
| Passwords of accounts, shared report logins and transport logins | Hashed | Stored only as a one-way bcrypt hash; nobody, the developer included, can read them back. A forgotten password is reset, never recovered. |
| Account and workspace details in the website's database: names, e-mail addresses, parish and workspace names, member lists, file names, sizes and dates, notes written when sending a version, notices to the team, names of archive folders and files | No | Protected by the database's access control, not by encryption. |
| Transport bookings (passenger names, phone numbers, amounts), support messages, training progress, the list of phones holding a copy, logs of logins and report views | No | As above. Keep sensitive details out of free-text notes and messages. |
| Web server logs | No | Record visitors' IP addresses, as every web server does. For downloads of program updates the country is looked up from the IP address through an outside service (ip-api.com). |
4. On phones and in the browser
| What | Encrypted? | How / notes |
|---|---|---|
| The offline copy on a phone (PRK Admin, PRK Finance) and its change notes | With a PIN | With a PIN set in the app, the copy and the change notes are encrypted (AES-256) with a key that only the PIN – or, for a forgotten PIN, the person's password – unlocks. Without a PIN the app encrypts nothing, and the copy is protected by the phone's screen lock (Android and iPhone encrypt their storage while locked). The parish can require a PIN on every phone. A shared report login receives only the figures of its own area, and never the baptism register. |
| A phone that should no longer hold the data | – | Every downloaded copy is registered. A phone deletes its copy and its change notes by itself the next time it is online when its person is removed from the workspace, its shared login is deleted, or an administrator clears that phone. A phone that never connects again keeps its copy – then only the screen lock and the PIN protect it. |
| Search pages and reports in a browser | On the way | Shown only to a signed-in member; decrypted on the server for that request. CSV files downloaded from them are plain files on that device. |
| Cookies and third parties | – | Only the sign-in cookie (HttpOnly). No advertising or tracking; fonts and scripts come from parishrecordkeeper.com itself. Tutorial videos (YouTube privacy mode, veed.io) contact their provider only when played. |
5. Who can read what
- Members of a workspace can download the parish data and use the online search of their own workspace only. Administrators manage members and versions.
- A shared report login sees only the area it was given and never the baptism register.
- A diocese receives only the copies the parish administrator chooses to send.
- The server itself must open the files to do its work – comparing versions, the online search, downloads. While a request runs, the key is in use and a temporary decrypted copy may exist; it is deleted when the request ends. Whoever has full control of the server account – the developer, and in principle the hosting company – could therefore read the data. The developer looks at parish data only when the parish asks (for example a support case it sends) and never sells, shares or analyses it.
What the encryption protects against – and what it does not
It protects against: someone reading the data on the way; a leaked copy or backup of the server's files or database; files altered or truncated on the server; a datafile with a password being copied or stolen.
It does not protect against: a parish computer left signed in; a datafile without a password; a phone with neither a screen lock nor a PIN; a weak or shared account password; a member passing on a file they downloaded; an attacker who takes over the whole server account (files and key together).
6. What the parish can do
- Set a database password on the datafile, and give it to team members in person or by phone – not in the same message as the file.
- Give the parish computer a Windows password, lock it when leaving it, and turn on disk encryption (BitLocker or Device Encryption) where Windows offers it.
- Give every person their own account; remove members who leave; use passwords of more than 8 characters that are not used elsewhere.
- Use a screen lock on every phone that holds an offline copy, set a PIN of at least 6 digits in the app – or let the administrator require one on every phone – and clear a phone's copy from the workspace page before it changes hands or when it is lost.
- Delete exports, CSV files and printed reports when they are no longer needed.
- Keep your own backups. The server copy is a convenience, not the parish's backup.
- Install the program only from parishrecordkeeper.com; its files are signed by the developer.
- A workspace administrator can delete the parish's data from the server at any time.
Technical summary (for IT advisers)
- Server files at rest
- AES-256-GCM (OpenSSL), envelope encryption: a 256-bit random master key in a file outside the web root and the database; one 256-bit random data key per scope (workspace, diocese, support), stored wrapped by the master key with AES-256-GCM. Files in 1 MiB frames, each with its own nonce and 128-bit tag; the header, frame index and a final-frame flag are authenticated, so reordering, truncation and tampering are detected.
- Online search copy
- One SQLite database per workspace, encrypted as a whole with the scheme above.
- Transport
- TLS on every connection; http redirected to https; HSTS (one year). Uploads: SHA-256 checked before use, one-time upload/download tokens.
- Passwords
- bcrypt via PHP password_hash(); minimum 8 characters. Session cookies HttpOnly, SameSite=Lax, Secure under HTTPS.
- Desktop datafile
- Microsoft Access (ACE) database password encryption, optional, applied to the whole file. The remembered password is obfuscated in the user's registry, not encrypted.
- Phone copy
- Browser IndexedDB. With a PIN: AES-256-GCM (WebCrypto) with a random data key, wrapped twice – by a key derived from the PIN (PBKDF2-SHA-256, 310,000 rounds) and by a random recovery key held on the server, sealed with the workspace's vault key and released only against the account password (5 tries per 30 minutes). Without a PIN: not encrypted by the app. Every copy is registered by a random id and deletes itself when access ends.
- Hosting
- Hostinger (shared hosting account). The master key and the encrypted files are on the same account: the scheme protects stored copies, backups and dumps, not a full compromise of the account.