[HN Gopher] Password managers less secure than promised
___________________________________________________________________
Password managers less secure than promised
Author : mono-bob
Score : 27 points
Date : 2026-02-21 21:35 UTC (1 hours ago)
(HTM) web link (ethz.ch)
(TXT) w3m dump (ethz.ch)
| mjamil wrote:
| Has there been a similar evaluation of 1Password?
| rorylawless wrote:
| 1Password wrote a response to the paper:
| https://1password.com/blog/eth-zurich-zero-knowledge-malicio...
| tempay wrote:
| It seems like 1Password is significantly more secure given the
| ratio of its market share to the number of articles I've seen
| like this one.
| kenniskrag wrote:
| > Much like the other products we analyse, 1Password lacks
| authentication of public keys. This trivially enables sharing
| attacks similar to BW09, LP07 and DL02, something that the
| 1Password whitepaper...
|
| > IMPACT. Complete compromise of vault confidentiality and
| integrity. The adversary can read and decrypt all vault con-
| tents encrypted after the attack, including passwords, credit
| card information, secure notes, and other sensitive data stored
| in the vault. Similarly, they can inject new items into the
| vault after the attack. REQUIREMENTS. The client fetches key
| material from the server, for example due to the user logging
| in on a new device. If executed on a non-empty vault, the
| attack results in the client losing access to all items already
| in their vault, while leaking any new items added to the vault
| after the attack took place. If the attack is executed at the
| time of vault creation, the attack is effectively undetectable
| by the client, since it cannot distinguish between a ciphertext
| it created and the ciphertext created by the server during the
| attack. PROPOSED MITIGATION. A straightforward mitigation is to
| have the client sign vault keys using the RSA private key in
| the keyset before encrypting them with the RSA public key.
| Ideally, two different key pairs would be used for...
|
| from the paper: https://eprint.iacr.org/2026/058.pdf
| fragmede wrote:
| https://x.com/IntCyberDigest/status/2023537803959660972
|
| 1password isn't in the clear either.
| baal80spam wrote:
| That's why KeePass is still the king. Offline vault > online
| vault.
| jmclnx wrote:
| >cloud-based password managers
|
| The main issue with these managers. I use an encrypted text file
| and Emacs, nothing on the cloud for me.
| doubled112 wrote:
| I'm not sure why anybody is surprised. Eventually, everything is
| proven to be less secure than promised, especially once they are
| online.
|
| There are certain types of data I prefer to have complete control
| over. Passwords, no matter how encrypted they claim to be, are
| top of the list.
| Sytten wrote:
| We will see when the attacks are public, a lot of the malicious
| server attacks we have seen in the past were kinda of overblown.
| Not discounting OP but it is very easy to get into clickbait
| territory.
| mberger wrote:
| Save you the click.
|
| The researchers demonstrated 12 attacks on Bitwarden, 7 on
| LastPass and 6 on Dashlane
| bstsb wrote:
| a better summary from the site:
|
| > We examine the extent to which security against a fully
| malicious server holds true for three leading vendors who make
| the Zero Knowledge Encryption claim: Bitwarden, LastPass and
| Dashlane [...] The attacks range in severity, from integrity
| violations of targeted user vaults to the complete compromise
| of all the vaults associated with an organisation.
| bstsb wrote:
| caveat not properly addressed in the blog post: all "attacks" are
| assuming full takeover of web servers, which is certainly a
| scenario that should be protected against, but isn't really a
| vulnerability unless chained with something else.
|
| almost all online services would be "vulnerable" in this way -
| take almost any login system. an RCE on a system hosting a login
| page would obviously be vulnerable to account takeover
|
| better link here (the technical details): https://zkae.io/
___________________________________________________________________
(page generated 2026-02-21 23:00 UTC)