🔎 Browsers as password managers under investigation: 🔐 Technical revolution or risky convenience? ⚠️

Image generated by OpenAI's DALL·E

---

Storing passwords in browsers has been a controversial topic for years. According to a study, over 34% of users use their browser's own password storage. While this practice offers considerable convenience, it also poses demonstrable security risks: For example, a 2023 ReliaQuest study found that approximately 21% of all password thefts originate from browser credential stores. Technological advances in recent years have addressed many of the previous vulnerabilities, but how robust are these security mechanisms? What specific technical risks still exist today, and how do they statistically compare to dedicated password managers?

Technical advances of modern password managers in browsers

Passwords were often stored insecurely in browsers in the past. For example, Firefox up to version 3.0 stored passwords unencrypted in the signons.txt file, making them vulnerable to simple file system-based attacks. Additionally, the use of unencrypted or weakly protected storage methods was also widespread in other browsers such as Internet Explorer. This meant that stored passwords could often be extracted using simple tools. Due to such security incidents, browser manufacturers have introduced crucial changes to provide much more robust password protection. Modern browsers now use significantly more complex mechanisms, including strong encryption technologies and hardware-based security solutions, to effectively address these previous vulnerabilities.

AES encryption and operating system-based storage

• Chrome and Edge (Chromium-based) store passwords encrypted in the SQLite database called Login Data.

  • Windows: Key management via the DPAPI (Data Protection API), which in turn links the key to the Windows user account. DPAPI uses AES-256-CBC for data encryption by default.

  • macOS: The master key is stored in the macOS Keychain and accessed via the KeyChain API.

• Firefox uses an internal SQLite database (logins.json and key4.db), with passwords encrypted with AES-256-GCM. The master key is secured either with a master password (derived from PBKDF2) or with system functions of the operating system.

Hardware-assisted security modules (TPM, Secure Enclave)

• TPM (Trusted Platform Module): Chrome benefits from TPM 2.0 through the underlying Windows security architecture (DPAPI, Credential Guard) to protect key material on the hardware side. The TPM generates and stores key material on protected hardware, making key extraction via software exploits significantly more difficult. Chrome does not directly use the TPM chip; rather, the DPAPI master key is secured by the TPM.

• Secure Enclave (Apple): Safari and Chrome on iOS and macOS store password keys. On Macs with Apple Silicon (M1, M2, M3) or T2 chips, passwords and cryptographic keys are stored in the Apple Keychain. Even if the operating system is compromised, the Secure Enclave prevents key material from being read or exported, as it never physically leaves the chip. Safari uses the Secure Enclave directly, while Chrome uses it indirectly via its API connection to the Keychain API.

WebAuthn and FIDO2

Modern browsers support WebAuthn (Web Authentication API), which is part of the FIDO2 standard. This allows users to log in either in addition to a password (two-factor authentication) or completely password-free – for example, with a hardware security key (e.g., YubiKey), biometric methods (Face ID, fingerprint, Windows Hello), or passkeys.

Since the private key never leaves the device and authentication is domain-bound, attacks such as phishing, credential stuffing, or password leaks are ineffective.

Continuing technical risks

Modern browsers and operating systems offer a variety of technical protection mechanisms for the secure storage and use of passwords – such as AES encryption, the use of TPM modules (on Windows), or the Secure Enclave (on macOS/iOS). Nevertheless, real attack vectors remain that can still be successfully exploited today.

Credential dumping by specialized malware

Tools like Mimikatz, RedLine Stealer, and Vidar impressively demonstrate how locally stored credentials can be extracted – even if they have been encrypted using DPAPI or similar mechanisms. These malware programs specifically access data decrypted in memory, read DPAPI keys from RAM, or dump entire processes to extract passwords in plaintext.

Attackers benefit from the fact that browsers temporarily store credentials in plaintext during use – a necessary step for auto-fill or logins. This becomes particularly critical when attackers can already act at the user or system level – for example, through successful privilege escalation.

RAM scraping and injection attacks

Memory dumping or DLL injection attacks also pose a significant threat. Direct access to the memory areas of browser processes allows passwords, session cookies, or auto-fill data to be extracted – even before they can be encrypted or deleted by modern security mechanisms.

In combination with tools like Cobalt Strike, ProcDump, or Process Hacker, attacks can be carried out that operate below the detection threshold of traditional antivirus solutions. Systems with outdated browsers or inadequately controlled user rights are particularly vulnerable.

Security vulnerabilities in browser extensions

Browser extensions are an often underestimated attack vector. Extensions often have extensive DOM and form access, providing an ideal gateway for JavaScript injection and man-in-the-browser attacks. Malicious code in extensions can read passwords as they are typed, manipulate forms, or exfiltrate data – often completely unnoticed by the user.

A well-known example is the compromised Chrome extension "Web Developer" in 2017. Attackers took over the extension, injected it with malicious code, and then distributed it via the official Chrome Web Store. Thousands of users were affected – their login credentials were stolen as they typed in the extension.

Phishing resistance: Passwords remain vulnerable

While in-browser password managers offer convenience, they don't protect against phishing attacks. Since the auto-fill feature doesn't perform a deeper check of the actual origin of a website, login credentials can also be entered into deceptively authentic forms—for example, on perfectly replicated fake logins.

From a technical perspective, the basic problem remains: A password is a shared secret – and as soon as it is transmitted or entered, it can be intercepted. Effective protection against phishing is only offered by technologies such as WebAuthn/FIDO2 with origin-bound keys, i.e., passkeys that only work for the legitimate domain and cannot be reused.

Technically superior alternatives

Modern password managers that operate independently of the browser offer a more robust security architecture. Their databases are typically encrypted with AES-256 in Galois/Counter Mode (GCM), with key derivation performed by PBKDF2, scrypt, or Argon2—methods specifically designed to protect against brute-force attacks and specialized hardware decryption.

A key advantage of these solutions is the clear separation between storage location and browser process. Passwords are not stored directly in the browser's memory, making attacks such as RAM dumping, memory injection, or DOM access manipulation significantly more difficult.

In addition, many solutions offer:

• Optional two-factor authentication

• Access logging and audit trails

• Cross-platform synchronization with end-to-end encryption

• Offline access with local protection mechanism

  
  

This technical separation and encapsulation makes dedicated password managers more resilient to client-side attacks, such as infected browser extensions, compromised websites, or compromised operating system processes. Some solutions are vulnerable to steal now, decrypt later attacks—especially with locally stored, weakly derived keys—and cloud services only offer as much security as the integrity and security of the respective provider allows.

Technical recommendation

Modern browsers today offer much more robust password storage than just a few years ago.

However, for critical accounts or sensitive applications, we recommend using a dedicated password manager, ideally in combination with multi-factor authentication and hardware tokens, to ensure a high level of protection.

Conclusion

Despite significant technological advances in password management by browsers, relevant vulnerabilities still exist, particularly through malware and compromised extensions.

For applications with high security requirements, the use of specialized password solutions remains the superior choice from a technical perspective. In corporate environments, centrally managed password managers with audit functions, access control, and policy integration should be preferred to ensure transparency, traceability, and security at the organizational level.