User Authentication for Tor Hidden Services: Balancing Security and Anonymity

Password storage must use modern cryptographic hashing algorithms. Argon2id is the current standard (winner of the Password Hashing Competition). bcrypt and scrypt are acceptable alternatives. MD5, SHA-1, SHA-256 without salting are not acceptable for passwords. Implementation: use your language's standard cryptographic library (Python: passlib with argon2-cffi, Node.js: argon2 package, Go: golang.org/x/crypto/argon2). Parameter recommendations for Argon2id: memory=65536 (64MB), iterations=3, parallelism=4. Store: $argon2id$v=19$m=65536,t=3,p=4$SALT$HASH. Never store passwords in plaintext, reversible encryption, or fast hashes (MD5/SHA-256). Salt must be unique per user (at least 16 bytes of cryptographically random data).

TOTP (Time-based One-Time Password) adds a second factor to hidden service logins. Implementation: generate a TOTP secret per user (base32-encoded random 20 bytes), store encrypted in the database. Users scan a QR code with Google Authenticator, Aegis (Android), or Raivo (iOS). Verification: TOTP algorithm generates a 6-digit code from the secret and current time (30-second windows). Verify in application: check current window and one previous (handles slight clock drift). Do not require users to provide phone numbers for 2FA setup - phone numbers compromise anonymity. Anonymous 2FA: provide the TOTP secret to users in plaintext (for use with any authenticator app without linking to an identity). Backup codes: generate 10 single-use backup codes at setup time, store hashed, distribute to user for recovery.

Tor's built-in client authorization (v3 client auth) provides strong authentication at the Tor protocol layer without requiring application-layer passwords. Each authorized client generates an x25519 keypair. The public key is added to the hidden service's authorized clients directory. Only clients with the corresponding private key can access the hidden service descriptor (and thus connect). This is suitable for: admin panels, development environments, private community hidden services. Configuration: on the hidden service server, create /var/lib/tor/hidden_service/authorized_clients/client1.auth containing the public key in the specified format. Client side: add ClientOnionAuthDir to torrc and place the private key file. This provides cryptographic authentication without passwords or user management.

Many hidden services should not require email for account creation (email is a deanonymizing factor). Anonymous account design: username (user-chosen, no email required), password only, optional (not required) TOTP 2FA, no recovery mechanism that requires external contact (recovery is impossible if credentials are lost). This is a deliberate choice for anonymity-preserving services: communicate clearly to users that lost passwords are unrecoverable. Some services provide one-time recovery codes at registration (stored by the user, not by the service). Captcha alternatives for registration abuse prevention: hashcash (computational proof of work), Tor's Proof of Work mechanism, or manual approval processes.

Session tokens for hidden service applications must be: cryptographically random (128 bits minimum, use cryptographic RNG not Math.random()), stored server-side with server-side expiry enforcement, transmitted in cookies with: HttpOnly flag (prevents JavaScript access), SameSite=Strict (prevents CSRF), Secure flag if HTTPS (not applicable for .onion HTTP but include for defense in depth). Session lifetime: balance security (shorter is better) with usability (users accessing through Tor may have slower connections, longer sessions reduce login frequency). 24-hour sessions with activity-based extension is a reasonable starting point. Implement concurrent session limits: maximum 3 active sessions per account to limit impact of session token theft. Provide users with a session management page showing active sessions and ability to revoke them.