I think compression would reduce the problem not? I think if you swap the wire format to something like jsonb you would need to parse it again anyway and pay the cpu time.
What's the threat model. Where do you store the decryption key?
E.g. if my app needs a db connection I can ask a vault service but I need creds for that. The vault service can rotate the creds very fast but is it addition security.
Banking has no selfservice password reset. A lot of work for customer support due to identification. Nobody wants to do that for free and if the accounts are freenyou may get DOSed by bots which trigger passwort resets.
A lot of services have password reset email features. If the email account has passkey you're screwed. But restore by snail mail can be possible but slow (for paid services). More secure? Don't know but same category of problems already known due to sim swapping attacks in mobile sector. But for sure the Mail account is a high value target.
Storing passkeys in a database may be possible but complex to do it right e.g. backup verification, avoiding to leak while backup etc.
> 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...
One reason was, that the security model wasn't enough anymore. E.g. every application was trusted and can listen to key inputs e.g. steal passwords and credit card infos. Btw there was an issue that screenshotting in wayland was not possible. But easy in X11 because everything was visible.
Don't know much about the architecture about wayland but I think grahic driver handling changed in wayland too.