29 ms·
While GP didn't spell this out, they have, in my opinion, a point. If you use a cloud portal, usually web based (be it browser, electron or similar), that asks
by rft 3y ago
While GP didn't spell this out, they have, in my opinion, a point. If you use a cloud portal, usually web based (be it browser, electron or similar), that asks for your master password, you need to trust the provider that the master password is not send to their servers. Even if you trust the provider to adhere to this principle, if their infrastructure is compromised an attacker can serve you a different webapp that sends your master password to the server. Same goes for auto-updating native apps.
This does not render the model of keeping the master password client side only moot, it is more secure no matter what. You successfully mitigate the read-only attack of dumping the storage of the cloud provider. However, if you assume a full, on-going compromise of the infrastructure, your password is not secure anymore.
I get that this is moving the goal posts a bit but I wanted to post this anyway. I think if you have highly valuable credentials and want the maximum security for them, you should play out as many possible attack vectors as possible.