Threat modeling the LAN sync in my wildlife app (as a beginner)
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
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 should NOT 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.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.