सुरक्षित लिंक शेयरिंग बेस्ट प्रैक्टिस: डाउनलोड URL सुरक्षित रखें
सुरक्षित डाउनलोड लिंक शेयर करने की बेस्ट प्रैक्टिस। URL टोकन सिक्योरिटी, लिंक एक्सपायरी और डाउनलोड लिमिट।
एक secure download link URL को ही key का हिस्सा मानता है। Slash के बाद का slug कम से कम 128 bits of entropy का होना चाहिए (जैसे hexatransfer.com/d/7Kj9xQmN2vP8rBwLsE4fT), घंटों में expire होना चाहिए न कि दिनों में, एक-दो attempts पर downloads cap होने चाहिए, और — critically — यह एकमात्र secret नहीं होना चाहिए। इसे URL fragment (# के बाद) में रखी password-derived AES-256-GCM key के साथ pair करें ताकि यह server log में कभी न जाए, और आपने Slack previews से corporate proxy archives तक सबसे common link-leak vectors defeat कर दिए।
Entropy: Guessability का गणित
Letters और digits के 6-character slug में 36^6 = 2.1 billion combinations हैं। बड़ा लगता है जब तक आप न सोचें कि botnet CDN के against 100,000 URLs per second test कर सकता है — यानी unauthenticated attacker roughly छह घंटों में full space enumerate कर लेता है। 128 bits (22 characters of base64url) तक बढ़ाएं और guess time sun की heat death से आगे जाती है। crypto.getRandomValues() उपयोग करें, कभी Math.random() नहीं, और कभी database ID encode नहीं करें। Sequential tokens हफ़्ते में दो samples collect करने वाले किसी भी व्यक्ति को transfer volume leak करते हैं।
Key को Fragment में रखें, Path में नहीं
URL में # के बाद सब कुछ fragment identifier है — browsers इसे server को नहीं भेजते। Decryption key वहाँ store करना वह pattern है जो Firefox Send ने pioneer किया: /#k=abc123xyz। Server केवल opaque download slug देखता है, इसलिए access logs, SIEM exports, और breach dumps में कोई key material नहीं है। CDN edge caches भी payload decrypt नहीं कर सकते। Slack unfurls URL probe करते समय fragment drop कर देते हैं, इसलिए preview bot key कभी नहीं देखता। यह single trick 80% practical link-interception attacks block करती है।
Threat के हिसाब से Expiry Windows
Default 7-day expiry ज़्यादातर use cases के लिए बहुत generous है। Workflow के अनुसार calibrate करें: bank को wire-transfer .pdf के लिए 15 minutes, contract review के लिए 4 hours, photo album के लिए 24 hours, async international collaboration के लिए ही 7 days। Signed URL payload में absolute UTC timestamp के रूप में expiry express करें और server-side enforce करें — client-side clock पर कभी trust नहीं। Expiry पर, disk पर ciphertext को zeros से overwrite करें (ideally NVMe पर blkdiscard के ज़रिए) ताकि बाद का disk forensics pass कुछ न पाए।
Download Counters जो Actually काम करते हैं
Single-download link airtight लगती है जब तक आपको पता न चले कि browsers aggressively partial transfers retry करते हैं। अगर Chrome 80% पर drop हो और नए Range request से resume हो, क्या यह दो downloads count करता है? Counter को file-completion boundary पर implement करें, HTTP request per नहीं। केवल तब increment करें जब final byte ship हो और auth tag verify हो। या, 10-minute window पर unique session IDs track करें: एक session = एक download, चाहे कितने Range requests issue हों। WeTransfer इन्हें conflate करता है और links को falsely consumed mark करने के लिए criticized हुआ है।
Short-Lived Tokens से Signed URLs
Enterprise flows के लिए, download URL को (slug, expiry, max_downloads, issuer_id) पर HMAC-SHA256 signature से wrap करें। Server कोई byte serve करने से पहले signature validate करे। S3 pre-signed URLs यह natively करते हैं; R2 और Backblaze B2 same pattern follow करते हैं। Signed URL जो Slack तक leak हो वह अभी भी dangerous है, लेकिन short expiry (जैसे 5 minutes) नुकसान limit करती है। इसे IP binding के साथ pair करें — signature expected /24 prefix include करे — link forwarding geographies में thwart करने के लिए।
Referrer और Preview Leaks रोकना
Browsers download page पर Referrer-Policy: no-referrer set किए बिना Referer header में full URL (minus fragment) भेजते हैं। उस header के बिना, download page से external link click करना destination पर हर tracker को slug leak करता है। X-Robots-Tag: noindex, nofollow और robots.txt भी set करें जो /d/ block करे, ताकि Googlebot forum पर accidentally paste हुए link को archive न करे। Slack और Teams previews के लिए, उनके unfurl bots matching User-Agents को 204 No Content return करें।
Forwarding Controls और Recipient Binding
एक बार Alice ने Bob को link send किया, Bob इसे किसी को भी forward कर सकता है। रोकने के लिए, link को Bob की identity से bind करें। बढ़ती strength में options: email verification (bob@firm.com पर one-time token), SMS verification (OTP to +1-415 number), first visit पर passkey registration, या Bob के Google Workspace के ज़रिए OIDC login। हर step friction के बदले containment trade करता है। GDPR Article 15 subject-access response के लिए, email verification आमतौर पर sufficient है। HIPAA-regulated lab result के लिए, passkey या OIDC belong करता है।
On-Demand Revocation
सभी guards के साथ भी, कुछ न कुछ गलत होगा — laptop stolen, contractor terminated, wrong recipient। Link को instantly kill करने वाला revoke button matter करता है। Implementation: slug hash पर keyed revocation list रखें, हर download पर check करें। Purge API के ज़रिए 60 seconds के भीतर CDN edges तक propagate करें (Cloudflare का /zones/:id/purge_cache URL list लेता है)। HexaTransfer revocation sender के dashboard से expose करता है; Dropbox Transfer और Smash दोनों support करते हैं लेकिन extra charge करते हैं। Quarterly revocation test करें — incidents के दौरान dead buttons नहीं करने से बुरे हैं।
Surveillance के बिना Telemetry
Abuse detect करने के लिए काफ़ी log करें (IP hash, User-Agent family, timestamp, bytes served) लेकिन recipient identity reconstruct करने के लिए नहीं। IPs को daily-rotating key से hash करें ताकि correlation windows छोटी रहें। URL fragment कभी log न करें। 30-day retention window SOC 2 Common Criteria 7.2 satisfy करती है surveillance archive बनाए बिना। Sender को dashboard में abuse counters expose करें ताकि वे देखें "AS15169 से 3 failed password attempts" और revoke करना जानें। DPDP Act 2023 के अंतर्गत यह data minimization approach India-based services के लिए compliance-friendly है।
hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।
एंड-टू-एंड एन्क्रिप्शन के साथ बड़ी फ़ाइलें सुरक्षित रूप से भेजें
एंड-टू-एंड एन्क्रिप्शन के साथ 10 GB तक की फ़ाइलें मुफ़्त में ट्रांसफ़र करें। अकाउंट की आवश्यकता नहीं। अपलोड से पहले आपकी फ़ाइलें ब्राउज़र में एन्क्रिप्ट की जाती हैं — कोई और उन्हें पढ़ नहीं सकता।
फ़ाइल भेजें