SnapPass: A 200-Line Lesson in Security Through Deletion

Hook

The most secure password is one that no longer exists. SnapPass takes this literally—secrets vanish the instant they're read, leaving attackers nothing to steal.

Context

Every developer has faced this scenario: you need to share a database password with a colleague, an API key with a contractor, or temporary credentials with a new team member. Email feels wrong—those messages live forever in inboxes, backup systems, and mail server logs. Slack or Teams aren't much better; messages persist indefinitely unless you remember to delete them. Encrypted email requires setup most people haven't bothered with, and enterprise secret management tools are overkill when you just need to share one password, right now.

SnapPass emerged from this exact frustration at Runscope (now part of BlazeMeter). The premise is deceptively simple: create a URL that contains a password, but make that URL work exactly once. After someone clicks it, the password disappears permanently. If it's never accessed, it expires automatically after a set time. This "read-once" security model—inspired by Snapchat's ephemeral messaging—means credentials have the shortest possible exposure window. No persistent storage, no accumulating liability, no forgotten secrets lurking in databases years later.

Technical Insight

SnapPass's architecture is a masterclass in doing one thing well. At its core, it's a Flask application backed by Redis, but the real elegance lies in how these pieces interact. When you submit a password through the web interface, Flask generates a cryptographically random token using Python's secrets module (or os.urandom in older versions), stores the password in Redis with that token as the key, and returns a shareable URL.

Here's the critical flow in simplified form:

import secrets
import redis
from flask import Flask, request, render_template

app = Flask(__name__)
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)

@app.route('/', methods=['POST'])
def set_password():
    password = request.form.get('password')
    ttl = int(request.form.get('ttl', 259200))  # 3 days default
    
    # Generate unguessable token
    token = secrets.token_urlsafe()
    
    # Store with automatic expiration
    redis_client.setex(token, ttl, password)
    
    # Return shareable URL
    link = f"https://yoursite.com/{token}"
    return render_template('confirm.html', link=link)

@app.route('/<token>')
def show_password(token):
    # Retrieve and DELETE in one atomic operation
    password = redis_client.get(token)
    if password:
        redis_client.delete(token)
        return render_template('password.html', password=password.decode('utf-8'))
    else:
        return "Secret not found or already viewed", 404

The genius is in what SnapPass doesn't do. There's no database schema to design, no user accounts to manage, no encryption-at-rest to implement (Redis handles the password as a simple string). Redis's SETEX command combines storage and TTL in one atomic operation, ensuring passwords automatically disappear even if never accessed—a critical defense against forgotten secrets accumulating in your system.

The token generation deserves special attention. Early implementations might have used sequential IDs or predictable hashes, making URLs guessable. By using secrets.token_urlsafe(), SnapPass generates tokens with enough entropy (typically 32+ bytes) that brute-forcing becomes computationally infeasible. An attacker would need to try trillions of combinations before guessing a valid URL, and with TTL expiration constantly removing tokens, the attack surface shrinks over time rather than growing.

The retrieval mechanism implements the read-once guarantee through Redis's GET followed by immediate DELETE. This isn't perfectly atomic in the code shown above—a more robust implementation would use Redis transactions or Lua scripting to prevent race conditions where two simultaneous requests might both retrieve the password. The actual SnapPass repository handles this carefully:

# More robust version using pipeline for atomicity
pipe = redis_client.pipeline()
pipe.get(token)
pipe.delete(token)
results = pipe.execute()
password = results[0]

This ensures that even if two people click the link simultaneously (say, if the URL gets indexed by a link preview bot), only one retrieves the password while the other gets a "not found" message.

The Flask routing is intentionally minimal—there's a homepage for creating secrets, an endpoint for retrieval, and that's essentially it. No admin interface, no password history, no "view again" option. These aren't oversights; they're deliberate security decisions. Every feature you don't build is one less attack surface, one less thing to maintain, one less potential leak of sensitive data.

Gotcha

SnapPass's simplicity is both its strength and its Achilles' heel. The biggest gotcha: there's zero authentication or access control. Anyone with the URL can view the password—anyone. If you paste that link in a public Slack channel, accidentally email it to the wrong person, or have it intercepted by network monitoring tools, game over. The password is as secure as the channel you use to share the URL itself.

Link preview bots are a particularly insidious problem. Modern chat applications and browsers automatically fetch URLs to generate previews, which means your "read-once" secret might be consumed by Slack's link unfurling service before your intended recipient ever clicks it. SnapPass has no way to distinguish between a legitimate human visitor and a bot, so the password gets burned immediately. Some deployments work around this with URL patterns that bots are less likely to crawl, but it's always a risk.

The lack of sender verification or audit trail creates a trust black hole. You have no way to confirm who accessed the password or when (beyond noting the link stopped working). If you're sharing credentials in a security-sensitive context, this opacity is unacceptable. You can't prove to an auditor that the right person received the password, and if something goes wrong, you have zero forensic data to investigate. For compliance-heavy industries, this alone disqualifies SnapPass from production use.

Finally, SnapPass is only as secure as your deployment. If you run it without HTTPS, passwords transit in plaintext. If your Redis instance is exposed to the internet without authentication, anyone can dump all active secrets. If you increase the default TTL to weeks or months, you've essentially recreated the persistent storage problem you were trying to avoid. The tool gives you enough rope to hang yourself if you're not careful about operational security.

Verdict

Use SnapPass if: you're sharing passwords ad-hoc with trusted colleagues over relatively secure channels (direct messages, authenticated chat), you value simplicity over features, and you need something deployable in 10 minutes that's still meaningfully more secure than emailing plaintext credentials. It's perfect for small development teams, sharing temporary database credentials, or one-off API key distribution where the recipient knows to expect a link and won't let preview bots consume it. Skip if: you need any form of access control, audit logging, or compliance documentation; you're sharing truly critical secrets (production encryption keys, root passwords) that justify purpose-built secret management infrastructure; or you can't guarantee the URL sharing channel itself is secure. In those cases, invest in HashiCorp Vault, use your password manager's built-in sharing (1Password, Bitwarden), or at least step up to alternatives like PasswordPusher that add recipient verification and view confirmations. SnapPass excels at being a lightweight 80% solution—recognize when your use case falls in the remaining 20%.