Has there been any research on the market share of password managers? Both from the perspective of competition (Bitwarden vs 1Password), but also users versus non users.
Conversation
Notices
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:40:07 JST Aaron Toponce ⚛️:debian:
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:40:04 JST Aaron Toponce ⚛️:debian:
@dimpase I'm familiar with pass(1). It has a horrible vulnerability in that it leaks all accounts to the filesystem. No modern password manager today does this.
LastPass got heavily criticized for not encrypting URLs in the DB, rightfully so, because it leaks which accounts a user has stored in the DB. They've since fixed it.
Also, PGP can die in a fire. Heh.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:40:04 JST Rich Felker
@atoponce @dimpase That is not what we call a "vulnerability", rather behaving correctly (not trying to lock the user's own data away from them in hidden storage they can't find, inspect, or backup).
It's arguably a "lack of hardening", but the hardening doesn't belong at this layer. If user needs protection against physical seizure, they use FDE and strong passphrase. If they need protection against malicious local apps, they run those on a different account or in a sandbox.
-
Embed this notice
Dima Pasechnik 🇺🇦 🇳🇱 (dimpase@mathstodon.xyz)'s status on Friday, 07-Feb-2025 01:40:06 JST Dima Pasechnik 🇺🇦 🇳🇱
@atoponce I know just one password manager which also doubles up as 2FA code generator. It's called pass, and it's a CLI application. It encrypts the data using GPG, and distributes/backs up data using git.
Just added a new key? Well, do "pass git push" to send it over, encrypted, to your git server. Yes, you'll need to do "pass git pull" on the other installs.
I can only complain that adding 2FA keys is somewhat painful. -
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:43:20 JST Rich Felker
@atoponce How would you do such research without either the pw manager having spyware in it (non-starter, and not counting any respectable one that doesn't) or some sort of sampling biased polling?
Some things just aren't knowable and that's okay.
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:45:10 JST Aaron Toponce ⚛️:debian:
@dalias @dimpase The vulnerability exposing accounts to the filesystem is closed if the data is not synced across computers and cloud providers. But if the data is synced, such as checked into GitHub or copied to Dropbox, the vulnerability is exposed.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:45:10 JST Rich Felker
@atoponce @dimpase "Data stored by the application is compromised if you're syncing it to somebody else's computer" is not a vuln in the application.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:46:32 JST Rich Felker
@atoponce Subreddit subscriber accounts is going to tell you which are popular with folks who use Reddit, a highly biased sample.
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:46:33 JST Aaron Toponce ⚛️:debian:
@dalias I was just curious. As a moderator of r/Passwords on Reddit, a user messaged me concerned about a certain post, which led to the discussion of biased and fair reporting of different password managers.
I used subreddit subscriber counts as a poor metric for market share, and mentioned as much, which got me curious if actual research had been done in this area. I figured it would be via voluntary polling, which has its own problems.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:48:26 JST Rich Felker
@atoponce @dimpase This applies to any data. Yes if you encrypt it locally before syncing, only the ciphertext is exposed. But you don't say your photos app has "a vuln exposing your nudes" when you sync to somebody else's computer.
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:48:27 JST Aaron Toponce ⚛️:debian:
@dalias @dimpase I disagree. Provided your master password is sufficiently secure, you can sync a KeePass/KeePassXC database safely to 3rd party servers without risk of revealing any information as to the number of accounts they contain, or which accounts are stored.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 01:59:36 JST Rich Felker
@atoponce @dimpase I'm pushing back strongly on calling this a "vulnerability". "Your private data is exposed if you sync it to somebody else's computer" is the default expected outcome. You can say "Y has stronger confidentiality properties than X because it has built-in encryption of the secret store", but this does not imply "X has a vulnerability". "Vulnerability" means something does not honor the documented or expected access controls or similar.
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 01:59:37 JST Aaron Toponce ⚛️:debian:
@dalias @dimpase The context is pass(1) however, not data in general. pass(1) reveals which accounts you're protecting, even if the password for each account is encrypted with your PGP keys.
Syncing encrypted pass(1) files to 3rd party cloud providers is a security vulnerability that other password managers does not have.
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 03:30:25 JST Rich Felker
@atoponce @dimpase What I find really weird is the notion that passwords for 3p services you have accounts on are more private/sensitive (need an application layer level of encryption) than personal data files (which generally have no such protection built-in).
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 03:30:26 JST Aaron Toponce ⚛️:debian:
@dimpase @dalias It is horrible. No password manager should be doing this. But it's not leading to the compromise of each account ("grave"), just leaking what they are ("bad", "horrible", "not good").
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 03:30:27 JST Aaron Toponce ⚛️:debian:
-
Embed this notice
Dima Pasechnik 🇺🇦 🇳🇱 (dimpase@mathstodon.xyz)'s status on Friday, 07-Feb-2025 03:30:27 JST Dima Pasechnik 🇺🇦 🇳🇱
-
Embed this notice
Dima Pasechnik 🇺🇦 🇳🇱 (dimpase@mathstodon.xyz)'s status on Friday, 07-Feb-2025 03:30:28 JST Dima Pasechnik 🇺🇦 🇳🇱
@atoponce @dalias all pass exposes are file names. Yes, indeed, if bazbar.gpg in your password store is revealing important info that you're a bazbar member, you're vulnerable to bazbar exploits.
But calling this a grave vulnerability is a bit farfetched
-
Embed this notice
Rich Felker (dalias@hachyderm.io)'s status on Friday, 07-Feb-2025 03:35:29 JST Rich Felker
@atoponce @dimpase You don't leak any metadata unless you're leaking your own private files to a third party (for example by using some awful non-e2ee someone-else's-computer storage service). And in that case, names of sites you have accounts on are the least of your compromise.
-
Embed this notice
Aaron Toponce ⚛️:debian: (atoponce@fosstodon.org)'s status on Friday, 07-Feb-2025 03:35:30 JST Aaron Toponce ⚛️:debian:
@dalias @dimpase I agree. What I don't understand why you would choose to leak metadata unnecessarily when stronger alternatives exist.
-
Embed this notice