Security & Encryption
What’s stored, and where
FileGriffon keeps everything locally, by default under
C:/ProgramData/FileGriffon/:
filegriffon.db— the SQLite database of files, hashes, and event historyparity/{vault}/— PAR2 recovery data- Timestamped
.baksnapshots (see Backups below)
Nothing about your file list or hashes is uploaded anywhere. (Telemetry, if you opt in, is a separate, minimal usage-stats stream — see Settings Reference.)
Hash keying
By default, both the fast “head hash” and the full-file hash are keyed
with an HMAC-SHA256 secret unique to your install before they’re stored
or compared. The secret itself lives in the Windows Credential Locker
(via DPAPI), not in the database file. This means a copy of your
filegriffon.db alone isn’t enough to derive meaningful hash values without
also having your install’s secret.
Each vault chooses its hash mode when it’s created, under Advanced:
- Protected (recommended, default) — hashes are HMAC-keyed as described above.
- Raw — hashes are stored as plain checksums, with no install secret involved. Useful if you want to compare them against an external tool’s own checksums directly.
This choice can’t be changed later, with one exception: a Raw vault can be upgraded to Protected at any time from its vault settings (a one-time, one-way action — Protected vaults can’t be switched back to Raw, since that would require re-reading and re-hashing every file rather than a simple conversion). A vault set to Protected and a vault set to Raw won’t be matched against each other for duplicate detection, since their hashes aren’t in a comparable format.
Database encryption
Settings → Security lets you:
- Enable encryption — sets a passphrase; the database is encrypted at rest (SQLCipher).
- Lock / Unlock — lock the database (e.g. before stepping away); unlocking requires the passphrase.
- Change passphrase
- Disable encryption
There is no password recovery. The passphrase is used in a one-way key derivation (PBKDF2) — if you lose it, you lose access to the database and its backups. Store it somewhere safe.
What “unlocked” protects against, and what it doesn’t. While the database is unlocked, your decryption key is held in memory so FileGriffon can keep monitoring in the background — this is true of any app that stays unlocked while running. It protects your data if the database file itself is copied or stolen (e.g. a lost drive, a backup that ends up somewhere it shouldn’t), but it can’t protect against someone who already has full access to this running machine. Lock the database (Settings → Security) when you want that extra layer, e.g. before stepping away.
Alert credentials
If you set up Email & ntfy Alerts (Pro), your SMTP
password and/or ntfy access token are stored the same way as the hash-keying
secret above — in the Windows Credential Locker, not in filegriffon.db or any
settings file on disk. Leaving the password/token field blank when saving
alert settings keeps whatever is already stored; it’s only overwritten when
you type a new value.
Cross-Machine Recovery Key
If you move your database to a new machine, hashes for your Protected vaults won’t match unless the new machine has the same HMAC secret. Settings → Security → Cross-Machine Recovery Key lets you export that secret (currently as plain hex — a passphrase-wrapped file export is planned) and import it on the new machine so history and hash comparisons keep working. Raw vaults aren’t affected by this at all — their hashes are plain checksums and move with the database as-is.
Backups
FileGriffon automatically writes an encrypted .bak snapshot on lock,
shutdown, or password change, and prunes older ones according to your
configured backup count. These are separate from PAR2 parity data — backups
protect the FileGriffon database (your scan history), not the files
being monitored.
Restore assistant
For files marked CORRUPT or MISSING that aren’t covered by parity (or
where parity can’t fix them), there’s a manual restore flow independent of
PAR2 — see Parity Protection for
the full behavior.