We could use passphrase to derive password directly. But this would skip the master secret derivation, essentially bypassing all custom-configured password-stretching parameters. This is bad in long term, as this does not allow to use better key-stretching parameters in future without breaking compatibility. It also cannot be salted by anything else than storage URL and username. Salting with storage URL and username has some drawbacks (mostly the need of exactly same URL and username, even if the backend tolerates some deviation like case), but they are probably justifiable.
We could also download some public data from the backup storage (this can hardly be storage-agnostic) to get key derivation parameters. Those key stretching parameters have to be considered as untrusted. This implies:
If we don't include passphrase_test in public parameters for key derivation, the backup storage can perform downgrade attack*: It can provide weak key stretching parameters and then bruteforce the password. (Rainbow attacks can be avoided, though: We can add URL and username to the salt.)
We can mitigate the downgrade attack by including passphrase_test in public parameters for key derivation. However, if we include passphrase_test in the public parameters for key derivation, anyone (not just the backup storage administrators) can download it and bruteforce master password offline.
Another disadvantage: This can increase practical value of shouldersurfing attacks.
However, maybe the hassle with design and implementation and all the risks are simply not worth of the enhancement.
*) Also anyone who can attack the connection can do this. So, the connection to backup storage is a new weak point.
This is a challenging task.
We could use passphrase to derive password directly. But this would skip the master secret derivation, essentially bypassing all custom-configured password-stretching parameters. This is bad in long term, as this does not allow to use better key-stretching parameters in future without breaking compatibility. It also cannot be salted by anything else than storage URL and username. Salting with storage URL and username has some drawbacks (mostly the need of exactly same URL and username, even if the backend tolerates some deviation like case), but they are probably justifiable.
We could also download some public data from the backup storage (this can hardly be storage-agnostic) to get key derivation parameters. Those key stretching parameters have to be considered as untrusted. This implies:
Another disadvantage: This can increase practical value of shouldersurfing attacks.
However, maybe the hassle with design and implementation and all the risks are simply not worth of the enhancement.
*) Also anyone who can attack the connection can do this. So, the connection to backup storage is a new weak point.