Password manager

Deployment models

Password managers may be standalone applications, browser extensions, or features built into a web browser. Some products are available in more than one of these forms. A desktop application may work with a browser extension to fill saved credentials into website login forms. Apple's iCloud Keychain can enable passwords and passkey synchronization across Apple devices approved by the user. In Google's ecosystem, passwords and passkeys can be saved to a Google Account and used to sign in to apps and websites on devices using that account.

A locally maintained password database is stored on the user's own device rather than on a provider-controlled server. Some standalone password managers require users to synchronize their vaults manually rather than providing built-in cloud synchronization. A vault file can instead be synchronized between devices through a separate file-sync service rather than through the password manager provider. A separate backup helps preserve access to a locally maintained password database if the device is lost or stolen.

In a cloud-synchronized password manager, encrypted vault data is kept on a remote server and synchronized with the user's devices. Some services allow organizations to run the storage server on their own systems instead of using the vendor's server. Bitwarden organizations can group shared records into collections and assign access to individual users or groups. 1Password Business provides administrative policies for authentication, sharing and permissions, and single sign-on.

History

Password management software dates back to the 1990s. PassKeeper was available by March 1996. The Microsoft Windows-based utility lets users to organize credentials and notes in an encrypted file. In September 1997, Counterpane Systems released Password Safe, a free utility for Windows 95. It stored its password database on the user's computer, protected it with Blowfish encryption, and used a single "Safe Combination" to access the saved passwords. The first version of 1Password, then named 1Passwd, was released on May 19, 2006 and LastPass was founded in 2008. Dashlane had been operating since 2012, and the open-source Bitwarden launched in 2016.

In June 2013, Apple announced iCloud Keychain for OS X Mavericks. The built-in password manager used iCloud to synchronize passwords only with trusted devices. By 2014, password managers were built into browsers, offered by third parties, and available on mobile platforms. Some also backed up passwords to the cloud and synchronized them across devices. In 2022, Google began rolling out a common password-management interface in Chrome and Android settings. Apple released the Keychain-based Passwords app in 2024 for accessing credentials including passwords, passcodes, and verification codes.

Security model

When properly implemented and used, a password manager makes it practical to use a different generated password for each account without having to remember them all. Use of password managers is associated with stronger password choices, particularly when a password generator is included. Because one vault may contain credentials for many accounts, the password manager and its master password are valuable targets for attack. One threat model assumes that the password manager server is fully malicious and may depart arbitrarily from its expected behavior. Under this model, expected protections include keeping vault contents secret, detecting unauthorized changes to vault data and metadata, and limiting sharing and account recovery to the intended users.

Vault protection

The master password is commonly used to create the key that encrypts the vault. An attacker who obtains a copy of an encrypted vault may try to guess its master password offline. To make offline guessing more expensive, password managers commonly apply deliberately slow password-based key derivation or hashing to the master password. In a 2020 evaluation, some password managers left particular metadata unencrypted, including site addresses, usernames, account-use information, or security-related settings, depending on the product. If integrity checks do not cover the vault as a whole, a malicious server may be able to alter, remove, or rearrange vault data without detection.

Autofill and phishing

Password managers generally associate stored credentials with particular websites and may decline to suggest or fill them when the current address does not match. Automatic filling can expose a stored password to malicious code on a compromised page without requiring the user to select the credential. In a 2014 test, six of ten password managers were vulnerable to an attack in which a rogue Wi-Fi network loaded login pages in invisible frames and captured autofilled passwords. Requiring the user to initiate filling prevents this kind of silent sweep attack, but user interaction alone does not eliminate all autofill risks.

A malicious website can also imitate the unlock interface of a password manager browser extension. In a 2025 phishing simulation involving 29,809 people at an educational institution, one of four targeted third-party password managers was detected in 448 participants. One hundred and forty of those users (31.25%) entered their master password into the imitation interface. A stolen master password can expose stored credentials, and phishing-resistant multi-factor authentication adds a separate barrier to using the stolen password.

Client security

A password manager's client can be targeted through malicious websites, rogue applications on the user's device, or adversarial networks. Browser-based autofill can be abused when credentials are released to a compromised page. User interaction prompts can themselves be exploited through clickjacking, where a deceptive page conceals or disguises the control being activated. These client-side and network attacks differ from offline attacks in which an adversary first obtains an encrypted copy of the vault.

Cloud storage, sharing, and recovery

Cloud-based password managers often describe their client-side encryption as "zero-knowledge encryption". In this usage, encryption is intended to prevent the provider from seeing the plaintext contents of the vault. The term has no strict technical definition. A 2026 analysis interpreted the vendors' security claims as implying protection even when the server behaves maliciously. That analysis identified 25 attacks against Bitwarden, LastPass, and Dashlane under this malicious-server threat model. The attacks involved weaknesses in account recovery and sharing, failures to verify public keys, incomplete protection against changes to an entire vault, and legacy cryptographic compatibility.

A 2024 study examined injection attacks in which a victim first accepts a shared item that the attacker can later update. Depending on the product, those updates could affect password-health metrics, site-icon requests, compressed vault size, or attachment deduplication. Across the ten password managers studied, different attack variants could reveal passwords, usernames, website addresses, or attachment contents. The first four vendors notified had deployed mitigations by the time of the study's publication, but disclosure to the remaining six was still underway. The paper described general-purpose detection and mitigation techniques against injection attacks as a direction for future research.

Password generation

The strength of a generated password depends on how unpredictably it is chosen and on settings such as its length and the characters the generator can use. A 2020 evaluation generated 147 million passwords and found a small fraction of shorter outputs vulnerable to guessing attacks, including passwords under 10 characters in its online-attack tests and under 18 in its offline-attack tests.

A flaw reported in Kaspersky Password Manager used the system time to seed a pseudorandom-number generator that was not intended for cryptographic use. Because system time was used as the seed, Kaspersky Password Manager could generate the same password on different installations during the same second. Information about when a password was generated could substantially narrow the guesses an attacker needed to try. Kaspersky rolled out fixes between October and December 2019 and added a warning in October 2020 telling users to regenerate affected weak passwords.

Usability and human factors

Password managers can reduce the burden of remembering many passwords, but using them also involves choices about trust, handling master password, password generation, and synchronization. When they do not work as intended, some users resort to less secure methods, such as reusing old weak passwords or recording passwords outside the password manager.

Adoption and trust

A 2019 interview study of 30 password manager users and non-users found that those who relied on password managers built into browsers or operating systems were often drawn to them by convenience, while users who had installed a separate password manager more often named security as a reason for doing so. Barriers to adopting a separate password manager included limited awareness, security concerns, a sense that there were too few passwords or little important data to justify using one, and discomfort with generated passwords that could not be remembered. Some participants were unsure whether password-saving prompts came from the browser, the website, or the computer, and also where saved passwords were stored or whether the provider could read them.

A 2021 interview study examined 26 adults over the age of 60, whose average age was 70.4 years. Participants expressed concern about cloud storage, cross-device synchronization, loss of control over private information, and the consequences of keeping many passwords behind one point of access. Recommendations and advice from family members or close friends were important influences on adoption among these participants.

Setup and routine use

A longitudinal study gave 37 first-time users a three-month password manager license and surveyed them weekly during the first month, with a final follow-up. Of the 33 who completed the first weekly questionnaire, 19 remained by week four, a 42% drop. Participants who later dropped out had lower first-week usability ratings than those who remained through week four. Reported trust increased over the study, while usability ratings among the 19 participants who completed all four weekly questionnaires stayed roughly stable.

Participants often found repeated master-password entry frustrating. When asked how they had created their master password, 44% of the responses described total or partial reuse of an existing password or personal information. By week four, 78.94% of the remaining participants had warnings for weak or reused passwords. Despite seeing the password-health dashboard each week, none of them changed those credentials during the study. Interviews in 2019 similarly found that users often retained weak or reused passwords when they first adopted a separate password manager and replaced them gradually over time.

Compatibility problems can interrupt registration or login when a password manager fails to offer password generation, saves or fills a credential incorrectly, or generates a password that the website rejects.

Effects on password practices

Using password managers is not consistently associated with stronger passwords or less reuse. Outcomes vary with how passwords are created, stored, and entered. A 2018 study surveyed 476 people and collected browser data from 170 of them. In the browser sample, users who relied on password generators had stronger passwords and less reuse than those who created passwords manually. Among recorded entries, 20% of Chrome-autofilled passwords and 25% of manually entered passwords were not reused, compared with 53% for LastPass and 78% for copy-and-paste. However, the study cautioned that the copy-and-paste subgroup was too small for firm conclusions.

In an online experiment using simulated browser password manager prompts, the prompt design was associated with whether participants used the generated password. Among 558 participants, 61.5% in the simulated Safari condition used the generated password, compared with 35.2% in the Chrome condition and 41% in the Firefox condition. The difference was statistically significant. Acceptance was higher among participants who noticed the prompt and among those who had used a password generator before. Prior password manager use itself was not significantly associated with acceptance.

Adoption

In a nationally representative Pew Research Center survey of 5,101 U.S. adults conducted in May 2023, 32% reported using a password manager, up from 20% in 2019. Reported use was 49% among adults ages 18–29 and 37% among those ages 30–49. For adults aged 50 or above, the share was 25% or less. Use also varied by education, where the reported use was 26% among adults with a high school education or less, 34% among those with some college education, and 38% among those with a bachelor's degree or higher.

The Australian Cybercrime Survey estimated secure password manager usage at 25.0% in 2023 and 26.8% in 2024, after adjusting for differences between the samples in both years. The survey did not use a nationally representative probability sample, and participants were drawn from opt-in online research panels. Sampling quotas covered age, gender and place of residence, while weighting accounted for age, place of residence, education, internet use and social-media use.

In an October 2024 online poll of 1,000 U.S. adults, 32% of password manager users primarily used Google Password Manager, followed by Apple's iCloud Keychain or Passwords app at 23%, LastPass at 11%, and Bitwarden at 10%. In the same poll, 79% of password manager users said that they paid nothing for the service.

Interaction with websites and applications

Web forms

On a website, a password manager needs to recognize which fields contain a username, an existing password, or a new password so it can handle the credentials correctly. The HTML autocomplete attribute can label these fields as username, current-password, and new-password, indicating what kind of value each field expects. Standard HTML forms, appropriate input types, and correctly chosen autocomplete values make it easier for password managers to recognize fields and offer the appropriate generation, saving, or autofill action.

Password managers can still run into problems when a site uses non-standard forms or password requirements that conflict with passwords generated by the password manager. Testing from June to December 2022 found registration or login usability issues on more than a quarter of the 61 websites for which testing was completed, but the rate varied among Chrome, Safari, Bitwarden, and Keeper. Among the 60 websites where passwords were generated, 19 rejected at least one password produced by the four tested password managers because it conflicted with the site's password requirements.

Restrictions and compatibility

Some websites have tried to limit password manager usage by blocking pasted passwords or by using HTML settings that ask browsers not to save or automatically fill login fields. In 2015, British Gas used onpaste="return false" on a password field and said it had chosen not to provide compatibility with password managers. Following criticism, the company said it would reconsider its approach. Paste restrictions were also found on T-Mobile, the German Barclaycard site, and Western Union. T-Mobile said its restriction was unintended and later removed it.

A site can use autocomplete="off" to ask the browser not to retain a field's value for later auto-completion, but modern browsers generally ignore it for username and password fields. For other fields, autocomplete="off" can still discourage later auto-completion. A password field meant for a newly assigned password can instead use autocomplete="newpassword".

The National Institute of Standards and Technology (NIST) guidance, NIST SP 800-63B, requires password verifiers to allow password managers and autofill, and recommends allowing passwords to be pasted when autofill APIs are unavailable. OWASP (Open Worldwide Application Security Project), in its Authentication Cheat Sheet, similarly recommends standard HTML username and password fields, support for passwords up to at least 64 characters and for printable characters, and the ability to paste into username, password, and multifactor authentication fields.

Native applications

Android version 8 and later versions provide an autofill framework that lets services such as password managers fill supported fields in other apps. A newer Credential Manager integration lets apps link username and password fields to credential requests, so credentials from available providers can appear in autofill suggestions.

Apple's Password AutoFill links an app to a website through an associated-domain relationship. Developers set this up by declaring the domain in the app's entitlement and publishing a matching association file on the website. Inline Password AutoFill suggestions are limited to credentials for the app's associated domains, but users can open the system credential list to choose another saved login. Developers can identify text fields as username, password, new-password, or other supported content types so Password AutoFill can present suitable suggestions.

Relationship to passkeys

Some password managers can also act as providers for passkeys, creating, storing, and managing them for the user. A passkey is a login credential based on public-key cryptography, using a public key stored by the service and a corresponding private key kept by the user's authenticator. Unlike passwords, passkeys do not require the user to send a shared secret to the website. The user instead approves the sign-in through the device or password manager, and the service verifies a cryptographic response.

A passkey may remain on one authenticator or be synchronized by a provider across several of the user's devices. Synchronization can make existing passkeys available on a replacement device without requiring the user to register a separate passkey for each device. A properly configured synced passkey is tied to the site for which it was registered, so an authentication response obtained by a phishing site cannot be reused at the legitimate service. When synchronized passkeys are backed up by a cloud-based provider, however, compromise of that storage can expose their private signing keys.