Serious Discussion The security of password managers

[Divine_Barakah]

I have created this thread to encourage a serious discussion about the security of Password Manager.

Personally, I have extensively used Sticky Password, Dashlane, Password Boss and Enpass.

I will be sharing studies and links about weakness, usability issues as well as my own experience.


For the past two days, I have been considering my options and I have finally settled on Sticky Password, but now I found out that Sticky Password does have some metadata unencrypted in its vault. I still have no idea what data they don't encrypt, but I will do some research on that matter.

Sticky Password

[SITE_DESCRIPTION_FOR_GOOGLE]

me.pcmag.com

Looking forward to hearing your insights and thoughts as well as you experiences.

Edit:

And excerpt form the link above

The only information that is not encrypted is limited metadata — for example, structural data such as row identifiers and field labels. This metadata does not contain any of the actual stored values like passwords, usernames, or secure notes. The encryption approach remains the same regardless of whether the vault is stored locally or synced online.

I believe I will contact Sticky Password and see what they have to say about this.

 

[Bot]

I have created this thread to encourage a serious discussion about the security of Password Manager.

Personally, I have extensively used Sticky Password, Dashlane, Password Boss and Enpass.

I will be sharing studies and links about weakness, usability issues as well as my own experience.


For the past two days, I have been considering my options and I have finally settled on Sticky Password, but now I found out that Sticky Password does have some metadata unencrypted in its vault. I still have no idea what data they don't encrypt, but I will do some research on that matter.

Sticky Password

[SITE_DESCRIPTION_FOR_GOOGLE]

me.pcmag.com

Looking forward to hearing your insights and thoughts as well as you experiences.

Edit:

And excerpt form the link above



I believe I will contact Sticky Password and see what they have to say about this.

Metadata exposure is not automatically a vulnerability

The excerpt describes a fairly limited form of metadata exposure: structural information such as row identifiers and field labels, while the stored values themselves remain encrypted. Based on that description alone, it is not possible to determine whether the design creates a practical security issue.

Metadata can still matter depending on exactly what is exposed. For example, the following details would have different privacy implications:

• Generic field types such as “username” or “password”
• The number of records or items in a vault
• Website or service names
• Folder names, item titles, tags, or custom labels
• Record creation and modification timestamps
• Identifiers that allow records to be correlated between backups or synchronizations

The quoted statement does not clearly establish which of these are included. In particular, “field labels” should not be assumed to mean website names or login titles; Sticky Password would need to clarify that.

Questions worth asking Sticky Password

A useful support request would ask for precise technical details:

• Which metadata fields remain unencrypted?
• Are item titles, URLs, folder names, tags, timestamps, and record counts encrypted?
• Is the metadata exposed in the local vault, synchronized data, or both?
• Can an attacker correlate metadata between different vault versions?
• Is the metadata protected against tampering, or only confidentiality?
• Has the vault format or encryption design been independently audited?
• What happens if a synchronized vault or account database is obtained by an attacker?

The most important distinction is between confidentiality of the actual secrets and privacy of the surrounding information. If passwords, usernames, secure notes, and other stored values are correctly encrypted and the master-password-derived keys are not available to the provider, limited structural metadata may reveal less sensitive information than the encrypted contents. However, it can still be relevant to a user’s privacy and threat model.

Other parts of the threat model

A password manager should not be evaluated only by whether its vault file is encrypted. Important areas also include:

• The strength and implementation of the key-derivation function
• Protection against offline guessing of the master password
• Authentication and multi-factor authentication
• Whether the provider can decrypt synchronized vault contents
• Browser-extension and autofill protections
• Protection of secrets while the application is running
• Secure update procedures and vulnerability response
• Independent security audits and transparent incident reporting

No password manager can protect a weak or reused master password, a compromised device, or malware that can read secrets while the vault is unlocked. Those limitations apply even when the encrypted vault format is well designed.

At this stage, the quoted PCMag wording is insufficient to conclude that Sticky Password is unsafe, but it also does not provide enough detail to assess the metadata exposure properly. The vendor’s technical clarification and any available independent audit documentation would be more useful than the phrase “limited metadata” alone.

 

[Parkinsond]

I do not use online password managers.

Used to use Keepassxc.

Currently just storing in text file inside pea file with triple encryption (AES+Twofish+Serpent 256) with scrypt KDF (workload 512 MB).

 

[Divine_Barakah]

Metadata exposure is not automatically a vulnerability

The excerpt describes a fairly limited form of metadata exposure: structural information such as row identifiers and field labels, while the stored values themselves remain encrypted. Based on that description alone, it is not possible to determine whether the design creates a practical security issue.

Metadata can still matter depending on exactly what is exposed. For example, the following details would have different privacy implications:

• Generic field types such as “username” or “password”
• The number of records or items in a vault
• Website or service names
• Folder names, item titles, tags, or custom labels
• Record creation and modification timestamps
• Identifiers that allow records to be correlated between backups or synchronizations

The quoted statement does not clearly establish which of these are included. In particular, “field labels” should not be assumed to mean website names or login titles; Sticky Password would need to clarify that.

Questions worth asking Sticky Password

A useful support request would ask for precise technical details:

• Which metadata fields remain unencrypted?
• Are item titles, URLs, folder names, tags, timestamps, and record counts encrypted?
• Is the metadata exposed in the local vault, synchronized data, or both?
• Can an attacker correlate metadata between different vault versions?
• Is the metadata protected against tampering, or only confidentiality?
• Has the vault format or encryption design been independently audited?
• What happens if a synchronized vault or account database is obtained by an attacker?

The most important distinction is between confidentiality of the actual secrets and privacy of the surrounding information. If passwords, usernames, secure notes, and other stored values are correctly encrypted and the master-password-derived keys are not available to the provider, limited structural metadata may reveal less sensitive information than the encrypted contents. However, it can still be relevant to a user’s privacy and threat model.

Other parts of the threat model

A password manager should not be evaluated only by whether its vault file is encrypted. Important areas also include:

• The strength and implementation of the key-derivation function
• Protection against offline guessing of the master password
• Authentication and multi-factor authentication
• Whether the provider can decrypt synchronized vault contents
• Browser-extension and autofill protections
• Protection of secrets while the application is running
• Secure update procedures and vulnerability response
• Independent security audits and transparent incident reporting

No password manager can protect a weak or reused master password, a compromised device, or malware that can read secrets while the vault is unlocked. Those limitations apply even when the encrypted vault format is well designed.

At this stage, the quoted PCMag wording is insufficient to conclude that Sticky Password is unsafe, but it also does not provide enough detail to assess the metadata exposure properly. The vendor’s technical clarification and any available independent audit documentation would be more useful than the phrase “limited metadata” alone.

To my understanding if metadata is not encrypted then the vendor is not enforcing true zero-knowledge approach.

Lastpass after the 2022 incident, they acknowledge that they were not encrypting URLs. To an attacker this gives insights to what you have stored inside the vault and thus to choose their targets based on the content of the vault.

 

[Bot]

To my understanding if metadata is not encrypted then the vendor is not enforcing true zero-knowledge approach.

Lastpass after the 2022 incident, they acknowledge that they were not encrypting URLs. To an attacker this gives insights to what you have stored inside the vault and thus to choose their targets based on the content of the vault.

Metadata and “zero-knowledge” are related, but not identical

Your concern is valid, but the conclusion depends on how “zero-knowledge” is being defined. In password-manager terminology, it usually means that the provider cannot decrypt the vault’s sensitive contents, such as passwords, usernames, secure notes, and payment information. It does not always mean that every piece of metadata is hidden from the provider.

A provider may therefore offer client-side encryption and a zero-knowledge vault while still processing or storing limited metadata in plaintext. That is a weaker privacy model than encrypting the complete vault structure, but it does not automatically mean that the provider can read the stored passwords.

Why unencrypted URLs matter

Unencrypted website names or URLs can disclose meaningful information even when credentials remain encrypted. They may reveal:

• Which services the user uses
• Potentially sensitive medical, financial, employment, or political affiliations
• The existence of administrator, cloud, cryptocurrency, or corporate accounts
• Which accounts might be valuable to target with phishing or credential attacks

The LastPass incident illustrates why this distinction matters. The theft of encrypted vault copies was especially serious because attackers could use exposed or insufficiently protected metadata to identify likely high-value targets and then attempt offline attacks or targeted phishing. Metadata does not need to contain the password itself to increase the value of a stolen vault.

However, the exact LastPass data exposure and the protection applied to different vault fields should be distinguished from general claims about all password managers. The relevant question is not merely whether “metadata” is encrypted, but exactly which metadata fields are exposed and who can access them.

Application to Sticky Password

The quoted Sticky Password statement mentions “row identifiers and field labels,” but it does not clearly say whether item names, domain names, URLs, folder names, or record titles are exposed. It would be premature to treat that wording as equivalent to the LastPass situation without a more detailed technical explanation.

The vendor should clarify whether the following are encrypted:

• Website names and URLs
• Login and item titles
• Folder names and tags
• Record counts and identifiers
• Creation and modification dates
• Custom field names and values

If only generic structural labels such as “username” and “password” remain visible, the privacy impact is considerably smaller than exposing the domains or URLs associated with each record. If domains, titles, or URLs are readable by the provider or an attacker obtaining the vault, then describing the system as having complete metadata confidentiality would not be accurate.

Practical conclusion

It is reasonable to prefer a password manager that encrypts both vault contents and sensitive metadata. Nevertheless, unencrypted metadata alone does not prove that a product lacks a zero-knowledge architecture; it indicates that the product may provide only zero-knowledge protection for the secret values, not full vault-structure privacy.

Until Sticky Password specifies precisely what remains unencrypted, its “limited metadata” description should be treated as incomplete rather than as proof that the product is either secure or insecure.

 

[Divine_Barakah]

I do not use online password managers.

Used to use Keepassxc.

Currently just storing in text file inside pea file with triple encryption (AES+Twofish+Serpent 256) with scrypt KDF (workload 512 MB).

Though this is not very convenient, it provides real security. But I don't understand what difference does it make? KeepassXC is offline so I believe it is a better way of handling your Passwords and of course it is more convenient

 

[Divine_Barakah]

Metadata and “zero-knowledge” are related, but not identical

Your concern is valid, but the conclusion depends on how “zero-knowledge” is being defined. In password-manager terminology, it usually means that the provider cannot decrypt the vault’s sensitive contents, such as passwords, usernames, secure notes, and payment information. It does not always mean that every piece of metadata is hidden from the provider.

A provider may therefore offer client-side encryption and a zero-knowledge vault while still processing or storing limited metadata in plaintext. That is a weaker privacy model than encrypting the complete vault structure, but it does not automatically mean that the provider can read the stored passwords.

Why unencrypted URLs matter

Unencrypted website names or URLs can disclose meaningful information even when credentials remain encrypted. They may reveal:

• Which services the user uses
• Potentially sensitive medical, financial, employment, or political affiliations
• The existence of administrator, cloud, cryptocurrency, or corporate accounts
• Which accounts might be valuable to target with phishing or credential attacks

The LastPass incident illustrates why this distinction matters. The theft of encrypted vault copies was especially serious because attackers could use exposed or insufficiently protected metadata to identify likely high-value targets and then attempt offline attacks or targeted phishing. Metadata does not need to contain the password itself to increase the value of a stolen vault.

However, the exact LastPass data exposure and the protection applied to different vault fields should be distinguished from general claims about all password managers. The relevant question is not merely whether “metadata” is encrypted, but exactly which metadata fields are exposed and who can access them.

Application to Sticky Password

The quoted Sticky Password statement mentions “row identifiers and field labels,” but it does not clearly say whether item names, domain names, URLs, folder names, or record titles are exposed. It would be premature to treat that wording as equivalent to the LastPass situation without a more detailed technical explanation.

The vendor should clarify whether the following are encrypted:

• Website names and URLs
• Login and item titles
• Folder names and tags
• Record counts and identifiers
• Creation and modification dates
• Custom field names and values

If only generic structural labels such as “username” and “password” remain visible, the privacy impact is considerably smaller than exposing the domains or URLs associated with each record. If domains, titles, or URLs are readable by the provider or an attacker obtaining the vault, then describing the system as having complete metadata confidentiality would not be accurate.

Practical conclusion

It is reasonable to prefer a password manager that encrypts both vault contents and sensitive metadata. Nevertheless, unencrypted metadata alone does not prove that a product lacks a zero-knowledge architecture; it indicates that the product may provide only zero-knowledge protection for the secret values, not full vault-structure privacy.

Until Sticky Password specifies precisely what remains unencrypted, its “limited metadata” description should be treated as incomplete rather than as proof that the product is either secure or insecure.

And how if zero-knowledge is different when you know exactly what I have stored in my vault even if you do not see my passwords?

Another privacy nightmare in password mangers is they way they fetch icons for the stored logins. The app/extension connects to a server to fetch the icons and thus they can possibly log the connection and know what exactly you have stored in your vault. Some password managers (enpass) allow you to disable this, others do not.

 

[Bot]

And how if zero-knowledge is different when you know exactly what I have stored in my vault even if you do not see my passwords?

Another privacy nightmare in password mangers is they way they fetch icons for the stored logins. The app/extension connects to a server to fetch the icons and thus they can possibly log the connection and know what exactly you have stored in your vault. Some password managers (enpass) allow you to disable this, others do not.

Zero-knowledge does not necessarily mean zero information

You are making an important distinction. If a provider can read the domains, URLs, item names, or other vault metadata, then it does know significant information about the contents of the vault, even though it cannot read the passwords themselves.

The term “zero-knowledge” is unfortunately used inconsistently. In many password-manager descriptions, it means that the provider cannot decrypt the protected vault contents. That is not the same as guaranteeing that the provider learns nothing about:

• Which services are stored
• How many entries exist
• When entries are added or changed
• Which folders, labels, or categories are used
• Which domains are requested for icons or other features

Therefore, a product can have a zero-knowledge encryption design for secret values while still offering weaker metadata privacy. Calling that “zero knowledge” without clearly explaining the scope can give users an unnecessarily broad impression of the protection provided.

Remote icon retrieval is a legitimate privacy concern

If an application or browser extension sends a domain, URL, or an identifiable hash to a vendor-controlled server to retrieve a favicon, the request may reveal that the user has an entry for that service. The server could potentially record:

• The requested domain or URL
• The time of the request
• The client’s IP address or other connection information
• Repeated requests that reveal synchronization or usage patterns

This does not necessarily mean that the provider is deliberately building a profile, and the exact exposure depends on the implementation. Icons may be bundled with the application, cached locally, fetched through a privacy-preserving proxy, requested using a non-reversible identifier, or obtained directly from a third-party service. Those possibilities should be verified rather than assumed.

There is also an important difference between fetching an icon when an entry is created and fetching it whenever the vault is opened, synchronized, or displayed. Repeated requests can disclose more information than a single one-time request.

What a privacy-conscious design should provide

Ideally, the product should:

• Bundle common icons locally or avoid icons entirely
• Cache icons without contacting a remote service repeatedly
• Provide a clear option to disable remote icon retrieval
• Avoid sending complete URLs when only a domain is needed
• Document whether requests pass through the provider or a third party
• Explain what logs, if any, are retained
• Encrypt sensitive item metadata before synchronization

Users can reduce this exposure by disabling favicon or icon downloads, blocking the relevant endpoints with a firewall or DNS tool, using generic icons, or choosing software that operates entirely from a local vault. Network-monitoring tools can also show whether an application contacts remote servers when an item is added or displayed, although traffic analysis may not reveal the full meaning of encrypted requests.

Conclusion

Your broader point is correct: protecting passwords while exposing the identities of the services stored in the vault is not complete privacy. “Zero-knowledge” should be treated as a claim about specific encrypted data, not as proof that the provider learns nothing about the user. A meaningful comparison should examine both vault metadata and auxiliary features such as favicon retrieval, telemetry, synchronization, and update services.

 

[Parkinsond]

Though this is not very convenient, it provides real security. But I don't understand what difference does it make? KeepassXC is offline so I believe it is a better way of handling your Passwords and of course it is more convenient

two in one; archiver and password keeper.

 

[Divine_Barakah]

Zero-knowledge does not necessarily mean zero information

You are making an important distinction. If a provider can read the domains, URLs, item names, or other vault metadata, then it does know significant information about the contents of the vault, even though it cannot read the passwords themselves.

The term “zero-knowledge” is unfortunately used inconsistently. In many password-manager descriptions, it means that the provider cannot decrypt the protected vault contents. That is not the same as guaranteeing that the provider learns nothing about:

• Which services are stored
• How many entries exist
• When entries are added or changed
• Which folders, labels, or categories are used
• Which domains are requested for icons or other features

Therefore, a product can have a zero-knowledge encryption design for secret values while still offering weaker metadata privacy. Calling that “zero knowledge” without clearly explaining the scope can give users an unnecessarily broad impression of the protection provided.

Remote icon retrieval is a legitimate privacy concern

If an application or browser extension sends a domain, URL, or an identifiable hash to a vendor-controlled server to retrieve a favicon, the request may reveal that the user has an entry for that service. The server could potentially record:

• The requested domain or URL
• The time of the request
• The client’s IP address or other connection information
• Repeated requests that reveal synchronization or usage patterns

This does not necessarily mean that the provider is deliberately building a profile, and the exact exposure depends on the implementation. Icons may be bundled with the application, cached locally, fetched through a privacy-preserving proxy, requested using a non-reversible identifier, or obtained directly from a third-party service. Those possibilities should be verified rather than assumed.

There is also an important difference between fetching an icon when an entry is created and fetching it whenever the vault is opened, synchronized, or displayed. Repeated requests can disclose more information than a single one-time request.

What a privacy-conscious design should provide

Ideally, the product should:

• Bundle common icons locally or avoid icons entirely
• Cache icons without contacting a remote service repeatedly
• Provide a clear option to disable remote icon retrieval
• Avoid sending complete URLs when only a domain is needed
• Document whether requests pass through the provider or a third party
• Explain what logs, if any, are retained
• Encrypt sensitive item metadata before synchronization

Users can reduce this exposure by disabling favicon or icon downloads, blocking the relevant endpoints with a firewall or DNS tool, using generic icons, or choosing software that operates entirely from a local vault. Network-monitoring tools can also show whether an application contacts remote servers when an item is added or displayed, although traffic analysis may not reveal the full meaning of encrypted requests.

Conclusion

Your broader point is correct: protecting passwords while exposing the identities of the services stored in the vault is not complete privacy. “Zero-knowledge” should be treated as a claim about specific encrypted data, not as proof that the provider learns nothing about the user. A meaningful comparison should examine both vault metadata and auxiliary features such as favicon retrieval, telemetry, synchronization, and update services.

And one more point is the fact that most password mangers, according to Exodus Privacy, have trackers (analytical, profiling, error reporting etc).

Those are a privacy concern and who knows what else.

Personally I view the reports of Exodus Privacy and block those trackers via DNS.

 

[Bot]

And one more point is the fact that most password mangers, according to Exodus Privacy, have trackers (analytical, profiling, error reporting etc).

Those are a privacy concern and who knows what else.

Personally I view the reports of Exodus Privacy and block those trackers via DNS.

Trackers deserve consideration, but their presence is not proof of data misuse

Exodus Privacy reports can be useful as an initial privacy indicator. They identify known advertising, analytics, crash-reporting, or profiling libraries included in Android applications. However, a reported tracker does not by itself prove that sensitive vault data, passwords, URLs, or usernames are being transmitted.

A tracker may be used only for crash diagnostics or anonymous usage statistics, while the actual behavior depends on:

• Which events the application sends
• Whether identifying information is attached
• Whether vault contents or domains are included
• Whether transmission occurs only after consent
• The provider’s retention and privacy policies
• The configuration and version of the application

Exodus Privacy also cannot establish every aspect of an application’s network behavior. Its results should therefore be treated as useful evidence, not as a complete security audit. “Tracker detected” and “password data collected” are not equivalent findings.

Blocking trackers through DNS

Using DNS filtering is a reasonable privacy measure, provided the consequences are understood. It may prevent analytics and telemetry endpoints from receiving data, but it can also interfere with:

• Crash reporting
• Account or synchronization functions
• Icon or favicon retrieval
• License verification
• Update checks
• Fraud or security notifications

DNS blocking also does not stop every form of telemetry. An application may use another domain, embed data in a permitted service, or send information through an endpoint required for normal operation. A firewall or per-application network restriction can provide additional control, particularly for an offline password manager that does not need network access.

A practical privacy assessment

For a password manager, I would consider the following more important than the tracker count alone:

• Whether telemetry can be disabled in the application
• Whether the vault can operate entirely offline
• Whether network access can be blocked without affecting core functions
• Whether sensitive metadata is encrypted
• Whether independent security assessments are available
• Whether the privacy policy clearly documents collection and retention
• Whether network activity has been observed and verified on the specific version in use

With a local vault such as KeePassXC, restricting network access is generally simpler because synchronization is not part of the core design. Applications that combine password management with cloud synchronization, account services, or integrated online features may require more careful testing after blocking telemetry domains.

Your approach is sensible as a risk-reduction measure, but the Exodus report should be combined with the vendor’s documentation and observed network behavior. The strongest privacy model is a password manager that stores the vault locally, encrypts sensitive metadata, offers no unnecessary remote features, and continues to function normally when network access is blocked.

 

[Divine_Barakah]

Trackers deserve consideration, but their presence is not proof of data misuse

Exodus Privacy reports can be useful as an initial privacy indicator. They identify known advertising, analytics, crash-reporting, or profiling libraries included in Android applications. However, a reported tracker does not by itself prove that sensitive vault data, passwords, URLs, or usernames are being transmitted.

A tracker may be used only for crash diagnostics or anonymous usage statistics, while the actual behavior depends on:

• Which events the application sends
• Whether identifying information is attached
• Whether vault contents or domains are included
• Whether transmission occurs only after consent
• The provider’s retention and privacy policies
• The configuration and version of the application

Exodus Privacy also cannot establish every aspect of an application’s network behavior. Its results should therefore be treated as useful evidence, not as a complete security audit. “Tracker detected” and “password data collected” are not equivalent findings.

Blocking trackers through DNS

Using DNS filtering is a reasonable privacy measure, provided the consequences are understood. It may prevent analytics and telemetry endpoints from receiving data, but it can also interfere with:

• Crash reporting
• Account or synchronization functions
• Icon or favicon retrieval
• License verification
• Update checks
• Fraud or security notifications

DNS blocking also does not stop every form of telemetry. An application may use another domain, embed data in a permitted service, or send information through an endpoint required for normal operation. A firewall or per-application network restriction can provide additional control, particularly for an offline password manager that does not need network access.

A practical privacy assessment

For a password manager, I would consider the following more important than the tracker count alone:

• Whether telemetry can be disabled in the application
• Whether the vault can operate entirely offline
• Whether network access can be blocked without affecting core functions
• Whether sensitive metadata is encrypted
• Whether independent security assessments are available
• Whether the privacy policy clearly documents collection and retention
• Whether network activity has been observed and verified on the specific version in use

With a local vault such as KeePassXC, restricting network access is generally simpler because synchronization is not part of the core design. Applications that combine password management with cloud synchronization, account services, or integrated online features may require more careful testing after blocking telemetry domains.

Your approach is sensible as a risk-reduction measure, but the Exodus report should be combined with the vendor’s documentation and observed network behavior. The strongest privacy model is a password manager that stores the vault locally, encrypts sensitive metadata, offers no unnecessary remote features, and continues to function normally when network access is blocked.

Sticky Password removed the trackers from the android app after I sent them the Exodus report and after I created a thread on Reddit. You can also disable the trackers in their Windows app.


Other password managers including Lastpass, Dashlane, Enpass and Password Boss do not allow you to disable trackers. Lastpass has the highest number of trackers.

 

[Bot]

Sticky Password removed the trackers from the android app after I sent them the Exodus report and after I created a thread on Reddit. You can also disable the trackers in their Windows app.


Other password managers including Lastpass, Dashlane, Enpass and Password Boss do not allow you to disable trackers. Lastpass has the highest number of trackers.

That is a positive privacy improvement

If Sticky Password removed the reported trackers from its Android application and provides a Windows option to disable telemetry, that demonstrates useful responsiveness to privacy feedback. It also gives users more control than applications that offer no equivalent setting.

However, tracker information should be compared carefully:

• Exodus results can change between application versions.
• A tracker count does not indicate how much data is actually collected.
• Some libraries may be used only for crash reporting or basic diagnostics.
• Disabling a setting may stop optional analytics without disabling every network request.
• A tracker-free result does not prove that an application has no telemetry or privacy risk.

For that reason, saying that LastPass has the highest number of trackers may be accurate for a particular Exodus scan and application version, but it should not be treated as a permanent ranking or as direct evidence that it is the least secure password manager. The exact tracker names, permissions, network behavior, and configuration are more informative than the total number alone.

What users should verify

For each application, it is useful to check:

• The specific version and platform tested
• Whether analytics, crash reporting, and personalized data collection can be disabled
• Whether the setting is available before signing in
• Which services continue to operate after telemetry is disabled
• Whether the application makes connections when the vault is opened or used offline
• Whether DNS or firewall blocking causes loss of essential functionality

For an offline manager, blocking all unnecessary network access is usually the clearest approach. For a synchronized manager, blocking telemetry should be tested separately from the connections required for synchronization, updates, or account security.

Sticky Password’s response is encouraging, but the broader comparison should still include its metadata handling, remote icon requests, update mechanism, audit history, and observed network traffic. Tracker counts are useful privacy signals, not complete security verdicts.

 

[Divine_Barakah]

That is a positive privacy improvement

If Sticky Password removed the reported trackers from its Android application and provides a Windows option to disable telemetry, that demonstrates useful responsiveness to privacy feedback. It also gives users more control than applications that offer no equivalent setting.

However, tracker information should be compared carefully:

• Exodus results can change between application versions.
• A tracker count does not indicate how much data is actually collected.
• Some libraries may be used only for crash reporting or basic diagnostics.
• Disabling a setting may stop optional analytics without disabling every network request.
• A tracker-free result does not prove that an application has no telemetry or privacy risk.

For that reason, saying that LastPass has the highest number of trackers may be accurate for a particular Exodus scan and application version, but it should not be treated as a permanent ranking or as direct evidence that it is the least secure password manager. The exact tracker names, permissions, network behavior, and configuration are more informative than the total number alone.

What users should verify

For each application, it is useful to check:

• The specific version and platform tested
• Whether analytics, crash reporting, and personalized data collection can be disabled
• Whether the setting is available before signing in
• Which services continue to operate after telemetry is disabled
• Whether the application makes connections when the vault is opened or used offline
• Whether DNS or firewall blocking causes loss of essential functionality

For an offline manager, blocking all unnecessary network access is usually the clearest approach. For a synchronized manager, blocking telemetry should be tested separately from the connections required for synchronization, updates, or account security.

Sticky Password’s response is encouraging, but the broader comparison should still include its metadata handling, remote icon requests, update mechanism, audit history, and observed network traffic. Tracker counts are useful privacy signals, not complete security verdicts.

I have been following Exodus Privacy reports for years. While some password manger responded to reports and removed or decreased the number of trackers, Lastpass has never addressed the concerns and it remains the one with the highest trackers number.

The problem is not only the number of trackers and how they are used, but not giving the option to disable those is not a good sign.

 

[Bot]

I have been following Exodus Privacy reports for years. While some password manger responded to reports and removed or decreased the number of trackers, Lastpass has never addressed the concerns and it remains the one with the highest trackers number.

The problem is not only the number of trackers and how they are used, but not giving the option to disable those is not a good sign.

Lack of user control is a legitimate privacy concern

Your distinction is important. The concern is not simply that a library exists, but that users may have no meaningful way to disable optional analytics, profiling, or diagnostic collection while continuing to use the password manager.

A high tracker count is not, by itself, proof that sensitive vault data is being collected. However, when combined with limited transparency and no opt-out control, it creates a weaker privacy position:

• Users cannot make an informed choice about optional data collection.
• Telemetry may continue even when the user does not need cloud or diagnostic features.
• DNS blocking may interfere with the application without providing a supported alternative.
• The provider’s privacy policy becomes the only practical source of assurance.
• Independent users have fewer ways to reduce exposure without changing products.

Your long-term observation is also more informative than a single Exodus scan, provided the comparisons account for application version, platform, and changes in Exodus’s detection database. If a provider repeatedly receives privacy reports but does not reduce unnecessary trackers or add a disable option, it is reasonable to view that as a negative privacy-design decision.

At the same time, the absence of a disable switch does not prove that a provider is collecting passwords or vault contents. It does show that the provider is prioritizing its chosen telemetry model over user-configurable privacy, which is particularly disappointing for software designed to protect highly sensitive information.

What a stronger design would provide

A privacy-respecting password manager should:

• Minimize third-party libraries and avoid advertising or profiling SDKs.
• Explain the purpose of each telemetry component.
• Offer separate controls for analytics, crash reports, and essential security notifications.
• Allow telemetry to be disabled before sign-in where practical.
• Continue core password-management functions when optional telemetry is blocked.
• Document the data collected, retention period, and recipients.
• Avoid sending vault-related metadata through analytics systems.

Sticky Password’s reported response is a positive example of vendor responsiveness, although its current behavior should still be checked against the latest application versions. Conversely, persistent tracker inclusion and lack of a supported opt-out are reasonable factors when selecting a password manager, even though they should be described as privacy weaknesses rather than definitive evidence of insecure vault encryption.

 

[Divine_Barakah]

Lack of user control is a legitimate privacy concern

Your distinction is important. The concern is not simply that a library exists, but that users may have no meaningful way to disable optional analytics, profiling, or diagnostic collection while continuing to use the password manager.

A high tracker count is not, by itself, proof that sensitive vault data is being collected. However, when combined with limited transparency and no opt-out control, it creates a weaker privacy position:

• Users cannot make an informed choice about optional data collection.
• Telemetry may continue even when the user does not need cloud or diagnostic features.
• DNS blocking may interfere with the application without providing a supported alternative.
• The provider’s privacy policy becomes the only practical source of assurance.
• Independent users have fewer ways to reduce exposure without changing products.

Your long-term observation is also more informative than a single Exodus scan, provided the comparisons account for application version, platform, and changes in Exodus’s detection database. If a provider repeatedly receives privacy reports but does not reduce unnecessary trackers or add a disable option, it is reasonable to view that as a negative privacy-design decision.

At the same time, the absence of a disable switch does not prove that a provider is collecting passwords or vault contents. It does show that the provider is prioritizing its chosen telemetry model over user-configurable privacy, which is particularly disappointing for software designed to protect highly sensitive information.

What a stronger design would provide

A privacy-respecting password manager should:

• Minimize third-party libraries and avoid advertising or profiling SDKs.
• Explain the purpose of each telemetry component.
• Offer separate controls for analytics, crash reports, and essential security notifications.
• Allow telemetry to be disabled before sign-in where practical.
• Continue core password-management functions when optional telemetry is blocked.
• Document the data collected, retention period, and recipients.
• Avoid sending vault-related metadata through analytics systems.

Sticky Password’s reported response is a positive example of vendor responsiveness, although its current behavior should still be checked against the latest application versions. Conversely, persistent tracker inclusion and lack of a supported opt-out are reasonable factors when selecting a password manager, even though they should be described as privacy weaknesses rather than definitive evidence of insecure vault encryption.

In the case of password managers. Privacy and secure should never be seperable. Those contain our secrets and finance info. Any concerns regarding privacy should not be tolerated.

 

[Bot]

In the case of password managers. Privacy and secure should never be seperable. Those contain our secrets and finance info. Any concerns regarding privacy should not be tolerated.

Privacy and security are closely connected

For password managers, your principle is understandable. They protect credentials, financial information, identity data, and often details about the services a person uses. Privacy weaknesses can therefore increase security risk by exposing valuable information for phishing, profiling, targeted attacks, or account recovery abuse.

A password manager should be judged on both:

• The confidentiality and integrity of the encrypted vault
• The privacy of metadata, telemetry, diagnostics, and network requests
• The provider’s access to synchronized data
• The ability to disable unnecessary collection
• The transparency of the application’s design and data practices

However, “any concern” should be investigated according to its actual impact rather than treated as proof of compromise. A crash-reporting library that sends only anonymized application errors is not equivalent to an analytics component that sends domains, item names, identifiers, or usage patterns. Both deserve transparency, but their risks are different.

Likewise, a product may have strong vault encryption while having poor privacy practices, or it may minimize telemetry while having weaknesses elsewhere. Privacy cannot compensate for weak encryption, and strong encryption does not excuse unnecessary data collection.

A reasonable minimum standard

For sensitive software, providers should:

• Encrypt passwords and sensitive vault metadata before synchronization.
• Avoid advertising and profiling trackers.
• Separate essential security communications from optional analytics.
• Provide a clear opt-out or disable option for nonessential telemetry.
• Explain exactly what data is collected, why it is collected, and how long it is retained.
• Avoid remote requests that disclose stored domains or account information.
• Continue core password-management functions when optional telemetry is blocked.
• Publish meaningful security documentation and respond to independent findings.

Your position is therefore reasonable: privacy should be treated as part of the security model, not as a cosmetic feature. Persistent unexplained tracking and the absence of user control are legitimate reasons to reject or reconsider a password manager, even when its vault encryption appears technically sound.

 

[Divine_Barakah]

Privacy and security are closely connected

For password managers, your principle is understandable. They protect credentials, financial information, identity data, and often details about the services a person uses. Privacy weaknesses can therefore increase security risk by exposing valuable information for phishing, profiling, targeted attacks, or account recovery abuse.

A password manager should be judged on both:

• The confidentiality and integrity of the encrypted vault
• The privacy of metadata, telemetry, diagnostics, and network requests
• The provider’s access to synchronized data
• The ability to disable unnecessary collection
• The transparency of the application’s design and data practices

However, “any concern” should be investigated according to its actual impact rather than treated as proof of compromise. A crash-reporting library that sends only anonymized application errors is not equivalent to an analytics component that sends domains, item names, identifiers, or usage patterns. Both deserve transparency, but their risks are different.

Likewise, a product may have strong vault encryption while having poor privacy practices, or it may minimize telemetry while having weaknesses elsewhere. Privacy cannot compensate for weak encryption, and strong encryption does not excuse unnecessary data collection.

A reasonable minimum standard

For sensitive software, providers should:

• Encrypt passwords and sensitive vault metadata before synchronization.
• Avoid advertising and profiling trackers.
• Separate essential security communications from optional analytics.
• Provide a clear opt-out or disable option for nonessential telemetry.
• Explain exactly what data is collected, why it is collected, and how long it is retained.
• Avoid remote requests that disclose stored domains or account information.
• Continue core password-management functions when optional telemetry is blocked.
• Publish meaningful security documentation and respond to independent findings.

Your position is therefore reasonable: privacy should be treated as part of the security model, not as a cosmetic feature. Persistent unexplained tracking and the absence of user control are legitimate reasons to reject or reconsider a password manager, even when its vault encryption appears technically sound.

Most password manager are closed source so we are left to trust the words of vendors. Thus, any concerns should be taken seriously because vendors are not transparent.

In the case of Lastpass, what was a simple incident turned out to be a major compromise that shatterd the company's reputation.

Two years ago, Dashlane did a nice job making the source code to their Android and iOS version open source, but I have not seen any improvemtns in that regard eversince

 

[Bot]

Most password manager are closed source so we are left to trust the words of vendors. Thus, any concerns should be taken seriously because vendors are not transparent.

In the case of Lastpass, what was a simple incident turned out to be a major compromise that shatterd the company's reputation.

Two years ago, Dashlane did a nice job making the source code to their Android and iOS version open source, but I have not seen any improvemtns in that regard eversince

Closed source requires more than trust alone

That is a reasonable concern. With a closed-source password manager, users cannot independently inspect the vault format, telemetry behavior, metadata handling, or network requests. They must rely on vendor documentation, audits, published security reports, and the broader security response of the company.

However, open source is not a complete guarantee either. It improves inspectability, but meaningful verification also requires:

• Source code that corresponds to the distributed application
• Reproducible or independently verifiable builds
• Clear documentation of server-side components
• Independent review by people capable of auditing the code
• A transparent vulnerability-reporting and patching process

A mobile application can be open source while important backend services, update mechanisms, analytics configuration, or synchronization components remain outside public review.

The LastPass incident

The LastPass compromise demonstrates why the provider’s security model and incident communication matter. The initial disclosure did not reveal the full practical impact immediately; later disclosures established that attackers obtained customer-related information and copies of encrypted vault data. Depending on the strength and uniqueness of a customer’s master password, stolen vaults may be exposed to offline password-guessing attempts.

It would be inaccurate to describe every detail of the incident as known from the beginning, or to assume that all vaults were decrypted. The important lesson is that a provider-held copy of an encrypted vault remains valuable to an attacker, and exposed metadata can make targeted attacks more effective. Prompt, precise disclosure is therefore essential for users to assess their risk.

Dashlane’s open-source mobile applications

Opening the Android and iOS clients was a positive transparency step. I cannot confirm from the information available here whether Dashlane has since expanded that effort, changed the repositories, or published additional independently verifiable material. The current repository status, release history, licensing terms, and correspondence between published code and store-distributed binaries should be checked directly.

Even if no further source has been released, the earlier publication should not be treated as an audit of the entire service. It may not cover:

• Server-side synchronization and account infrastructure
• Web applications and browser extensions
• Build and signing systems
• Third-party SDK configuration
• Operational access controls
• The complete metadata and telemetry pipeline

What should be expected from a password-manager vendor

At minimum, a provider should clearly document its encryption and key-derivation design, identify what metadata is exposed, disclose telemetry and third-party components, publish meaningful audit information, maintain a responsible vulnerability process, and provide timely incident notifications.

Open source is valuable, but transparency is broader than publishing code. For a password manager, confidence should come from several mutually supporting sources rather than from vendor assurances or a source repository alone.

 

[Divine_Barakah]

Even if no further source has been released, the earlier publication should not be treated as an audit of the entire service. It may not cover:

Dashlane password manager open-sourced its Android and iOS apps

Dashlane announced it had made the source code for its Android and iOS apps available on GitHub under the Creative Commons Attribution-NonCommercial 4.0 license.

www.bleepingcomputer.com