A short password on a password-protected link feels like a reasonable compromise. The note is encrypted, the link is private, and a few digits are easy to dictate. But once somebody obtains the address, automated guessing changes the situation. Without limits, a service can become a convenient password-checking machine. Speed depends on password strength, processing cost and hardware, not a universal promise about cracking something in seconds.
Burn-on-Failure makes mistakes spend a limited resource: available views. That is useful, but browser-side encryption creates an important boundary. Secure Link cannot promise that deleting a server record stops somebody testing a copy they already downloaded. Understanding that distinction is more valuable than another reassuring security slogan.
Two attacks: online API guessing and offline guessing
Online guessing needs requests to the service. A server that verifies passwords can throttle those verifications. Secure Link works differently: decryption happens locally, so the server does not know whether a password was correct. It counts encrypted-note retrievals and failure reports from the client.
Offline guessing starts after an attacker obtains ciphertext and the parameters needed to decrypt it. Candidates can then be tested locally, without API requests. View counters and TTL cannot control that copy. For Decoy Mode, opening the outer container additionally requires the fragment key from the link.
AES-GCM authentication lets a decryptor recognize a successful result. A single captured copy may therefore be enough for continued guessing. A one-view link limits retrieval, not every operation somebody performs on bytes already delivered.
How Burn-on-Failure works in Secure Link
Fetching an encrypted note atomically decrements its Redis view counter. At the final view, the active record is removed while the requesting client receives the encrypted data. With 1 view, server deletion consequently happens before the recipient knows whether their password will decrypt the note.
If password decryption fails, the standard client sends a separate consume-view request. Reaching zero deletes the record; remaining views allow further attempts through the interface. This is client-reported failure handling, not server-side verification of every password candidate.
A modified client can omit that report and keep testing downloaded ciphertext. Deleting the record after a few reported errors cannot make its saved copy disappear. Burn-on-Failure constrains subsequent server retrieval and ordinary interface behavior; password strength and cryptography protect the copy itself.
PBKDF2-HMAC-SHA-256 makes each password derivation cost computation. The current standard password mode uses 200,000 iterations; Decoy Mode uses 100,000. A random salt prevents reusing the same precomputed work across notes. Neither salt nor repeated computation adds missing password entropy. A predictable PIN remains predictable, just more expensive to test.
A separate layer is HMAC-SHA-256 rate limiting. The application derives a pseudonymous identifier from the client address, a server secret and an API scope. The limiter stores that identifier rather than the raw IP in Redis, without associating it with note contents. Network infrastructure still processes addresses; this is not a claim that IP information never exists anywhere.
HMAC is not the password derivation function and does not strengthen the recipient's password. It supports request counters without raw-IP persistence in the limiter. API limits and per-note views address different resources. Neither can slow computations on an offline copy.
Comparing three delivery methods
| Property | Password ZIP in chat | Ordinary password link | Secure Link: Burn-on-Failure |
|---|---|---|---|
| Copy available to recipient | Downloaded archive | Depends on implementation | Retrieved ciphertext can be copied |
| Failed-attempt limit | Usually none after download | Depends on server verification | Standard client consumes views after failures |
| Source deletion | Does not erase downloaded archives | Depends on TTL and settings | Active Redis record removed by views, TTL or manual burn |
| Offline guessing | Possible against a saved archive | Possible with required data | Still possible; a strong password matters |
Implementations vary. Before sending access, ask what the recipient can download and which controls remain enforceable afterward.
What if the recipient mistypes the password?
Typing on a phone is unforgiving. Choosing 3 views leaves more room, but does not guarantee three password guesses: the initial retrieval already spends one, and reported failures spend additional views. Decoy Mode currently enforces a minimum of three views even if the sender chooses fewer.
- Generate a long, random password with a password manager instead of choosing a memorable PIN.
- Deliver the extra password through a separate channel, not alongside the link in the same message.
- Set a short TTL for the handoff. Expiry limits server availability, not the lifetime of downloaded data.
- If a link is unexpectedly exhausted, contact the recipient. For sensitive access, revoke or rotate the underlying credential before sending a replacement.
An empty link is not proof of a successful attack: expiry, accidental retrieval or an ordinary typo can explain it. Still, issuing a fresh URL does not revoke an API token that may have escaped.
Use the protection within its limits
Create a one-time link with an appropriate view budget and a strong additional password. Burn-on-Failure reduces ordinary retries and future server retrieval. It is a useful control, not remote deletion of somebody else's files and not a substitute for credential rotation.