Yes you’re right, and what you suggest here is what will be happening on the network.
Account access will be done through a ‘root secret key’. The standard way to use the root secret key will be by combining several other secrets together (called key shares). The user is mainly interacting with key shares, not the root secret key directly.
From a technical angle, the combining of key shares into a root secret key is done using the threshold crypto scheme in the blsttc crate (previously threshold_crypto crate).
The problem here is the underlying password would only be as strong as the weakest file.
With threshold crypto it’s not enough to compromise any one credential, the attacker needs at least a certain number of keyshares before they can combine them into the root secret key.
This will still be possible. An advanced user could choose to set their own root secret key and not do any of the key management stuff.
It really comes down to how permissions work on the network. The account is accessed by reading a private bit of data on the network. That private account data can only be read by providing a signature from the root secret key. The way the user chooses to generate that signature (the obvious way using a single key, or using a threshold signature scheme, or using some other third-party way of generating a signature) is at the app level, not the network level.
What maidsafe is aiming at is the root secret key being secure by default, which means more than just being an X characters long password or being stored in Y different locations. The ability to revoke a key share from a device without changing the root secret key is one of the important aspects that’s possible when using key shares as the main point of contact (ie keeping the root secret key ‘hidden’ behind the layer of key shares). If we were directly trying to manage the root secret key the revocation process becomes more difficult.