Yes, if you don't care about GERS™ knowing which sites you use, when you add accounts to them, when you chance passwords, and all the other sensitive informatio

Yes, if you don't care about GERS™ knowing which sites you use, when you add accounts to them, when you chance passwords, and all the other sensitive information that can be extracted from metadata. > would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name? In that case you duplicate the metadata: You keep one datum in plain text for search purposes, and a second for MAC/verification purposes. That's a somewhat awkward construction, and you can accidentally create new security holes in your application (by using the MAC'd metadata at point A and the plain metadata at point B – there's a bunch of high-profile CVEs created this way). Alternatively, you can MAC the metadata separately from the password. However, (H)MAC involves a secret key that must not be shared in plain text. So you'd need encryption anyway to be able to verify the MAC key. In either case you still allow a few attacks: Attackers can delete entries (DoS), attackers can selectively replace entries with older versions (DoS or information leakage if the password still works), and probably a few others. Using the password AEAD to encrypt the whole database, not just passwords, not just individual entries, is not just safer, but also reduces complexity.