How Does Dave by voolama Protect Against Brute-Force Login Attacks?

Four login security controls are documented in the feature-summary help documentation for Dave by voolama (hellodave.ai), DEV v0.11.0, confirmed 2026-08-30. All four are configurable at Admin, then Settings, then General, then Access. Each default value is independently verifiable in the UI. No vendor trust required. Independent third-party validation requires a security audit: this table documents the application-layer controls only.

Rate limiting applies to three endpoints: sign-in, session refresh, and sign-up. The feature-summary help documentation states: "Sign-in, session refresh, and sign-up are automatically throttled per device, so rapid-fire guessing and automated attacks are blocked before they can reach an account." Throttling is per device: a script cannot bypass the limit by rotating source addresses on the same machine.

NIST SP 800-53 Rev 5 AC-7 (Unsuccessful Login Attempts, section 7a) requires enforcing a limit of consecutive invalid login attempts. AC-7 section 7b requires locking the account for a defined period. The 3-attempt default with a 5-minute lockout satisfies both AC-7 section 7a and section 7b. GDPR Article 32 requires appropriate technical measures for data security: the four controls in this table are the technical measures Dave by voolama applies at the authentication layer. Whether this satisfies a specific compliance obligation is a legal question outside the scope of this article. Independent validation requires a third-party security audit.

Five password complexity presets are available in Dave by voolama (hellodave.ai). Configured at Admin, then Settings, then General, then Access. Sourced from the feature-summary help documentation, DEV v0.11.0, confirmed 2026-08-30. Verify: navigate to Admin, then Settings, then General, then Access, open the Password Policy section, and count the preset options. Five options are present. No vendor trust required.

NIST SP 800-63B section 5.1.1.2 requires: "Verifiers shall compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised." OWASP ASVS v4.0 section 2.1.7 requires: "Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords." Only the Enterprise preset includes a common password blocklist check and satisfies both requirements. The Basic, Standard, and Strong presets do not include a blocklist check. Independent validation of whether the blocklist implementation satisfies these requirements requires a third-party security audit.

Three password expiration modes are available: all passwords, non-admin only, or no forced expiration. Expiration period is configurable from 15 to 90 days. Force-change-after-reset is enabled by default. OWASP ASVS v4.0 section 2.1.9 requires that passwords set or reset by administrators require a change at next use: the Dave by voolama default satisfies section 2.1.9. Verify: reset a test user's password as Admin, log in as the test user, confirm a password change prompt appears before the dashboard loads. No vendor trust required.

Two additional controls complete the login security stack in Dave by voolama (hellodave.ai). Sourced from the feature-summary help documentation, DEV v0.11.0, confirmed 2026-08-30.

CAPTCHA. Four provider types are available: reCAPTCHA v2 (Google challenge-response, requires user interaction), reCAPTCHA v3 (Google risk-score, invisible to users), hCaptcha (privacy-focused challenge-response, GDPR-oriented alternative to reCAPTCHA), and Cloudflare Turnstile (non-intrusive browser attestation, no user interaction required). OWASP ASVS v4.0 section 2.2.1 lists CAPTCHA as a recognised control for preventing automated credential-stuffing attacks. Configured at Admin, then Settings, then General, then Access. Verify: enable CAPTCHA, navigate to the login page, confirm a CAPTCHA challenge appears before the password field is submitted. No vendor trust required.

JWT session management. Sessions use stateless, tenant-scoped JWT tokens with a configurable expiry (default 60 minutes). Refresh token rotation invalidates the previous refresh token on each renewal. The feature-summary help documentation states: "Previous refresh tokens are invalidated on each renewal to prevent replay attacks." OWASP ASVS v4.0 section 3.3.1 requires that logout and expiry invalidate session tokens: rotation-on-renewal satisfies section 3.3.1. NIST SP 800-63B section 7.1 requires session management to limit the window of exposure from a stolen token: the 60-minute default and rotation-on-renewal together satisfy section 7.1. Verify: log in, trigger a refresh, attempt to reuse the old refresh token. It is rejected. No vendor trust required.

These application-layer controls operate above a separate infrastructure layer. Dave by voolama applies 18-step CIS/NIST-aligned server hardening as part of managed hosting. CIS Controls v8 Control 5 (Account Management) and Control 6 (Access Control Management) apply at the server level. The application-layer controls documented in this article are independently verifiable in the UI; the server-hardening layer requires a CIS Benchmark audit or third-party penetration test for independent validation. Both layers are distinct and independently auditable. MFA is a separate control from login security. See How Do I Enforce Multi-Factor Authentication for My Team in Dave by voolama? for the full MFA configuration guide.

This article covers the four login security controls and five password presets in Dave by voolama (hellodave.ai) at DEV v0.11.0. Three things it does not cover:

• Independent third-party validation. This article is sourced from the vendor's own help documentation and confirmed against a specific code commit. Independent validation of whether these controls satisfy a specific security standard requires a third-party penetration test or CIS Benchmark audit. This article documents the controls as configured; it does not certify them as effective against any specific threat model.
• MFA enforcement. Multi-factor authentication is a separate control from login security. See How Do I Enforce Multi-Factor Authentication for My Team in Dave by voolama? for the full MFA configuration guide, including the eight MFA provider types, grace period, trusted device duration, and backup codes.
• Legal compliance advice. This article cites NIST SP 800-63B sections 5.1.1.2, 5.2.2, and 7.1; OWASP ASVS v4.0 sections 2.1.7, 2.1.9, 2.2.1, and 3.3.1; CIS Controls v8 Controls 5 and 6; and NIST SP 800-53 Rev 5 AC-7 as frameworks. Whether the login security configuration described here satisfies a specific contractual or regulatory obligation is a legal question. This article is not a substitute for a formal security assessment.