@jehunter5811.id the “restoring of IDs” (that is, the derived ones within the same login) is trivial and way too easy to be considered as a blocker for this issue. One could just store the offsets to regenerate within the profile.json for when you restore an account, though there are easier/simpler/safer solutions than this as well. I don’t believe multiple-root-IDs (that use different recovery phrases) will ever be implemented due to security risks, etc.
@Jenayers93 Blockstack works a little differently in that you never “reset your password.” Your recovery key is tied to your account – I.E. if you even changed one word within the phrase you would generate an entirely different address (if it was valid at all), as the address is derived from the phrase.
The recovery (private) key is never stored in plaintext, and the only way it could be gathered is if they get it in the (rather) small amount of time where you either recover your account or view it (by re-entering your password to temporarily show it in the browser app/settings). Otherwise, it can not be easily cracked via the encryption as the official browser uses three layers (or if you are using my extension, just AES-256), which leaves only the dictionary attack left – though that should take much too long due to the size of the dictionary used.
Thus the only real concern – which is discussed here – should be having an attacker able to access a live session, such as through a stolen phone or if one used a public computer and forgot to log out. Currently there is no way to “end” a session remotely – so they could technically do anything you can do, except for get your recovery key or do anything that requires your password or key phrase.
This is definitely an issue that should be looked into as ending sessions is rather important – perhaps this could be done by keeping a
sessions.json active within the gaiahub and, if the official browser(s) detect that they are no longer allowed then they log out by themselves. This is obviously able to be bypassed by more experienced hackers but it’s a start.
Another way would be to use “democratized-but-still-centralized nodes” to handle user authentication and session management. This would be like using the core-node to sign people in and handle the important things… but it could be run by the user themselves (similar to a gaia hub) if they wanted that security. This may be the safest but least decentralized way to do it, but it is something to look into.