Abuse protection
How PulsVault resists brute force and credential stuffing — automatic IP blocking, rate limiting, progressive delays, account lockout, and nonce-based replay defense.
Zero-knowledge encryption protects data at rest; abuse protection defends the authentication surface itself. PulsVault layers automatic IP blocking, rate limiting, account lockout, and transport replay defenses so that credential-guessing attacks are throttled, blocked, and logged long before they threaten an account.
Automatic IP blocking#
Failed logins are tracked per source IP inside a sliding time window. Once too many failures
accumulate in that window, the IP is blocked outright and receives 403 Forbidden before any
credential is processed.
Each failure is recorded with its IP, geolocation, user agent, and timestamp; recent failures are counted and the block is applied automatically when the limit is crossed. Blocks are temporary and expire on their own — the sliding window prevents permanent lockouts — and admins can unblock manually or whitelist trusted networks.
The exact limits, window lengths, and block durations are deliberately not published, and they are tuned over time.
Enforcement is the first thing that runs#
The IP block check runs before authentication — ahead of token validation and any credential processing — so blocked traffic is rejected at minimal cost. Block state is cached so lookups stay fast under attack and enforcement takes effect immediately across every server instance.
Rate limiting and account lockout#
IP blocking targets sources; three further controls target volume and accounts:
- Per-IP rate limiting — request volume from a single IP is throttled independently of whether authentication succeeds or fails.
- Progressive delays — failed logins incur exponential backoff, making online guessing economically pointless even below the blocking limit.
- Account lockout — a per-account counter locks the account after sustained failures for a cooldown period, catching distributed attacks that rotate IPs against one account.
- Session creation limits — session-creation rate limiting and a concurrent-session cap bound what a compromised credential can do.
Replay and transport integrity defense#
Beyond TLS and HSTS, sensitive requests carry integrity metadata: an HMAC-SHA256 request hash, a unique nonce, and a timestamp. The server rejects duplicate nonces and requests older than a short acceptance window, defeating capture-and-replay of otherwise valid requests. Even if transport were broken, secret fields are already client-side encrypted — an interceptor sees ciphertext inside ciphertext.
Monitoring and hygiene#
- Every block, threshold breach, and geographic anomaly is recorded to the audit log and surfaced as security events.
- Alerting triggers include sustained single-IP attacks, coordinated multi-IP patterns, and unusual geographic activity.
- Expired blocks and stale attempt records are purged on a routine schedule, with separate retention tiers for attempts, blocks, and analytics data.
Bot filtering (rejecting scripted user agents) and the login hardening described in Authentication security complete the picture.
Related#
- Authentication security — login hardening in context
- Security reports — attack visibility for admins
- Threat model