Yes, the initial situation during the time frame between an ‘invite’ and ‘sign up’ for Bob allows for the scenario you describe.
However, I believe the outcome (apart from the fact that Mallory actually gets to open the file) is that Bob will call Alice and ask what’s going on? Bob can’t sign in to the account – and the end result is that Bob will become aware that his email is compromised.
If the attack is initiated *after* Bob has actually signed up for AxCrypt, there is no vulnerability to this attack at all.
The private key is initially stored on our server when an invite happens, encrypted with our key. As soon as Bob (or Mallory for that matter) sets a password, the private key is re-encrypted with that password.
This is the ‘convenience’ track. Should Alice *really* want to be assured that this does not happen, she should contact Bob and ask him to sign up before the file key is shared.
It’s a situation where we feel that practicality is so great in *not* requiring Alice to contact and wait for Bob to set everything up is worth the attack window.
What’s stopping an attacker from changing the key on our servers, is our servers of course. Except for the ‘invite’ window scenario, an intruder with access to the server can’t access or decrypt any private keys just as little as we can ourselves.
The private keys are also synchronized to your local device, and can even be generated there if you are running offline when you register. And, yes, you can export the key pair (both private and public as one file). It’s under the following menu:
File | Key Management | Export AxCrypt ID Secret and Sharing Key Pair