[CyberRage]

Encryption\Decryption are done locally. the server has no clue what your master-key is, all it knows here's a blob of data you need to store, here's my "ID"(The secondary key generated which is different from the encryption key and also relies on the master-key and other parameters).

When retrieving the vault, the program will generate the secondary key, provides it to the server(You can add 2FA btw), the server sees that indeed it matches one of the ID's and sends you back the encrypted vault. decryption is done locally.

I don't see any issue with this process, maybe you care to point the attack vector\scenario

[fuoqi]

Leaking the secondary key will allow an attacker to impersonate user at any time and to continuously retrieve the encrypted vault. As I've said, it may not be important for a password storage, but in more sophisticated applications continuous access to an encrypted vault may leak important meta-information (e.g. number of files, their size, time of creation, etc.).

[CyberRage]

As I've mentioned, when retrieving the vault other parameters need to match like Account name, Email etc.

You can add 2FA to the authentication process.

All metadata is obviously encrypted, the data is just a single blob. you maybe could try to guess the number of entries based on size but that's too dynamic as well.

These products were attacked before, decrypting the vault wasn't how they were attacked.

It was with bugs\vulnerabilities within the browser extensions that lead to data leaks. something else entirely.