The Problem 🚨
Currently, BeamSync uses a single static 64-character hex token for authentication that lives for the entire application session. If that token gets saved in a browser's history, dumped into a local log file, or leaked via an HTTP referer header, an attacker gains permanent access to download files for the duration of that session.
Furthermore, the token has no structural tie to the machine serving the files. We want to overhaul this by switching to short-lived, single-use tokens that are cryptographically locked to the specific network context.
Architectural Design 🛠️
1. The Token Store
Ditch our primitive string matching and build a robust token structure in the Go backend. Every generated token must contain:
- Its raw string value
- Creation and expiration timestamps (Default TTL: 5 minutes, with sliding renewal triggered via web client heartbeats)
maxUses and useCount limits (Single-use for files, multi-use for persistent heartbeats)- A
boundFingerprint matching the server's TLS certificate.
2. Cryptographic HMAC URL Binding
When generating data-transfer URLs or QR links, calculate an HMAC signature to lock the parameters down:
token = HMAC-SHA256(serverSecret, sessionID || tlsFingerprint || clientIP || expiration)
The backend must re-verify this hash on every incoming request. If someone copies the token but tries to access the endpoint from a different IP address, or after the 5-minute window closes, the server must reject the handshake immediately with an HTTP 403.
3. Graceful Expiry Cleanup
If a client stops sending background heartbeats for over 5 minutes, tear down the token registry. The client web view should intercept the resulting 403 error and cleanly display a friendly reconnect/re-scan prompt.
Where to Look 📂
beamsync/server.go — Rewrite generateToken() and tokenMiddleware() to support the new validation lifecycle.beamsync/ui/upload.html & download.html — Update the JavaScript handlers to process short-lived token updates and handle the reconnect UI flow gracefully.
The Goal 🎯
- Ensure tokens auto-expire within a tight 5-minute sliding window.
- Lock token validity strictly to the originating TLS fingerprint and client IP path.
- Prevent token spoofing by enforcing server-side HMAC validation.
The Problem 🚨
Currently, BeamSync uses a single static 64-character hex token for authentication that lives for the entire application session. If that token gets saved in a browser's history, dumped into a local log file, or leaked via an HTTP referer header, an attacker gains permanent access to download files for the duration of that session.
Furthermore, the token has no structural tie to the machine serving the files. We want to overhaul this by switching to short-lived, single-use tokens that are cryptographically locked to the specific network context.
Architectural Design 🛠️
1. The Token Store
Ditch our primitive string matching and build a robust token structure in the Go backend. Every generated token must contain:
maxUsesanduseCountlimits (Single-use for files, multi-use for persistent heartbeats)boundFingerprintmatching the server's TLS certificate.2. Cryptographic HMAC URL Binding
When generating data-transfer URLs or QR links, calculate an HMAC signature to lock the parameters down:
The backend must re-verify this hash on every incoming request. If someone copies the token but tries to access the endpoint from a different IP address, or after the 5-minute window closes, the server must reject the handshake immediately with an HTTP 403.
3. Graceful Expiry Cleanup
If a client stops sending background heartbeats for over 5 minutes, tear down the token registry. The client web view should intercept the resulting 403 error and cleanly display a friendly reconnect/re-scan prompt.
Where to Look 📂
beamsync/server.go— RewritegenerateToken()andtokenMiddleware()to support the new validation lifecycle.beamsync/ui/upload.html&download.html— Update the JavaScript handlers to process short-lived token updates and handle the reconnect UI flow gracefully.The Goal 🎯