Threat-modeling the LAN sync in my wildlife app (as a beginner)

Amged — Sat, 10 Oct 2026 04:34:28 +0000

I'm new to programming & have been teaching myself security by building things and then poking at my own assumptions. This is a simple threat model for one feature of Wildlife Incident Handoff, it's an opensource Windows app for recording wildlife incidents and handing them off between people.

Now the feature is LAN sync: I wanted to make it so two paired devices on the same local network can exchange incident records directly with no cloud involved. It's opt in and still experimental although It has not been independently reviewed, so this post is "how I designed it and where I know it's weak," not "it's secure."

What I'm protecting

Incident records. They can include sensitive animal locations and private contact details, which shouldn't leak.

What could go wrong, and what I did about it

Threat	In plain English	My defense	Known gap
Eavesdropping	Someone on the same wifi reads the data	Data is encrypted (AES-256-GCM) with a key both devices agree on (P-256 ECDH + HKDF)	Keys are long-lived, so there's no forward secrecy unless I rotate keys or re-pair
Impersonation	Someone pretends to be my other device	Each install has its own keypair and a fingerprint you can compare	On a hostile network, it only works if people actually compare fingerprints
Stolen pairing code	Someone learns the code and tries to pair	The first device has to manually approve every request	A human has to read the prompt carefully
Replay	Someone records a message and sends it again later	Each message carries a counter, and old counters are rejected, even after a restart	Limited testing so far
Strangers reading data	An unpaired device asks for records	The sync endpoint rejects untrusted devices	A tiny "ping" endpoint still answers for discovery (it returns no incident data)
"Disabled" isn't fully off	Sync is turned off but something is still listening	Pairing and sync requests are rejected when sync is disabled	The network listener stays open while the app runs

What I haven't covered

A device that's already trusted but compromised
Attachments (they don't sync)
Wide testing across different routers, VPNs, and corporate networks
An outside security review

What I learned

Writing this made me notice that "disabled" in my app means "refuses requests," & not "stops listening." Those aren't the same thing and I want to fix it so the listener only runs when sync is on

If you find a hole please report it through the repo's SECURITY.md instead of opening a public issue.

DEV Community: Amged

Threat-modeling the LAN sync in my wildlife app (as a beginner)

What I'm protecting

What could go wrong, and what I did about it

What I haven't covered

What I learned