Privacy Browser Brave Launches Accounts: Passwords Stay on Device
Privacy browser Brave has announced the launch of Brave Accounts, allowing users to utilize newly introduced Email Aliases and access future Brave services.
Authentication uses the OPAQUE protocol, corresponding to the enhanced password-authenticated key exchange in RFC 9807. The device blinds the password with a random value and performs a forgettable pseudorandom function with the server, which processes it with its own key without seeing the plaintext; the device then generates an authentication key using Argon2id, and the server only retains an encrypted envelope that is useless without the password. During login, both parties prove their identities and negotiate a new session key, with the password and its direct hash never leaving the device. The company claims that even if the database is stolen, attackers would still need the server key and cannot perform offline bulk collisions on the entire database. OPAQUE does not prevent phishing, and weak passwords can still be guessed online.
Email Aliases were launched with desktop version 1.94, separate from Brave Premium subscription accounts. Users can directly generate forwarding aliases in the registration box, hiding the main email from websites to cut off cross-site email tracking. Brave retains the account email and generated aliases; emails are deleted from the server within seconds of delivery; alias notes only exist on the device, and if Sync is enabled, they are end-to-end encrypted. Forwarding uses Amazon SES with static encryption; logs retain fields such as delivery time, alias ID, email ID, and spam/virus determination, without recording the body or sender, with statistics deleted after 7 days and logs after 14 days. Users can create up to 5 aliases for free. The entry point is at brave://settings/email-aliases.
The sync layer will be integrated later. The new Brave Sync can pair with Accounts, eliminating the current QR code link while retaining account-less sync. The official emphasized that users are not forced to use an email to sync, and sync data remains end-to-end encrypted. The backend open-source repository exposes the OPAQUE server's public and private keys, PostgreSQL, and AWS RDS configurations, and can use fake records to suppress account enumeration.
In market mechanisms, this is a product feature launch, not a token or ad auction event. The buyers are users unwilling to provide their real email to websites, and the sellers are Brave, using the account system to support VPNs, aliases, and future service login layers. If funding does not occur, it will reflect in Premium conversion and retention of ad-blocking products; beneficiaries are users wanting to reduce cross-site tracking, while the pressured parties are websites and analytics firms relying on email as a cross-site identifier. Phishing and weak password risks remain on the client side and do not disappear due to protocol changes.
In supplementary statements, the alias feature previously appeared in Nightly as an experimental switch and is now in the stable channel; the account system is written as a unified entry point for future services, rather than replacing local data encryption.
Source: Public Information
ABAB AI Insight
Brave's introduction of accounts acknowledges that pure account-less sync is no longer sufficient to support new products. QR code sync leaves keys on the device chain but prevents Email Aliases, VPN renewals, and more future cloud features from having a recoverable identity anchor. OPAQUE offers a compromise: the server can verify "you know the password" but cannot access the password itself, thus framing "an account is necessary" and "the company cannot see the password" within the same mathematical framework. RFC 9807 was formalized in July 2025, and Brave has advanced it from paper specifications to browser login, moving ahead of most websites that still use salted hashes, and is more robust than the PR claim of "we only store hashes."
The capital and product paths align: first, use aliases to create a necessity for login, then simplify Sync with accounts, allowing key export to serve as a root for end-to-end functionality without issuing a separate recovery code. Email forwarding is hosted on AWS SES, indicating that the privacy narrative stops at the authentication layer, while the delivery layer still relies on large clouds. Offering 5 free aliases and parallel Premium accounts creates a funnel for privacy features: free solves email exposure, while paid accounts continue to sell VPNs. The accounts service on GitHub has written OPAQUE keys and RDS into environment variables, and the engineering has been built with an auditable backend rather than local browser scripts.
The analogy is not with Google accounts, but with password managers like 1Password that keep secrets on the client side and only place verifiers on the server, as well as Apple's hidden email feature. Brave is transitioning from a "anti-tracking browser" to a "privacy suite with identity." The community has pointed out that the Sync QR code can be displayed on the device without secondary verification, and the new account pairing is a product-level fix for this old attack surface while retaining the account-less option to prevent open-source users from leaving.
Structural changes belong to technical substitution. Website logins have long handed passwords or hashes to servers, and a leak equals offline collision of the entire database; OPAQUE changes the collision cost to "each account plus server key." The mechanism is: blinding prevents the server from seeing the password during registration, envelope encryption renders stolen databases useless, mutual authentication blocks man-in-the-middle attacks, but phishing pages can still trick users into revealing the same password. Once privacy browsers start issuing accounts, competition shifts from intercepting scripts to who can minimize secret exposure under the premise of "must log in."
ABAB News · Cognitive Law
Passwords do not leave the device, but that does not mean passwords on phishing pages are secure.
Account-less sync is convenient, but accounts are necessary to connect new services.
Passwords invisible to the server still require users to choose strong ones.