At present, the password is playing a double role now:
it is used to encrypt the keystore
it is used by meteor authentication
This presents all kind of complications if the user has two keystores on two different devices for the same account. For example, resetting the password on one device will, of course, not reset the password of the keystore on the second device.
Furthermore, the meteor password handling is a centralized part of our app - i.e. not in the spirit of what we want to to, and something to phase out in any case.
Proposal: use the keystore for meteor authentication
We could implement a system in which meteor identifies users by their Ethereum address, and users authenticate by sending a signed message to meteor.
This would imply the following flows:
Account creation
User arrives on device and navigates anonymously (no action required, everything is transparent, the player is in complete control of the keystore)
At certain points, user has the option to "take control of his wallet". At this point, the user has two options:
2a. Create a new account. User is assked for name, email, etc. She will choose a password, and receive a keyphrase to regenerate the keystore
2b. Use an existing account. The user is asked for the keyphrase, which will generate a keystore for the exsting ethereum address. She will also be asked for a password (which may or may not be the same as the password on another device)
Password reset
Password reset is device dependent, and will create a new keystore only on the device where the password reset flow has been initiated.
user clicks "reset password"
user is given some explanatino and the option to either insert the old password or the keyphrase
user chooses new password
a new wallet is generated with the old keyphrase and the new password
Password handling on multiple devices
At present, the password is playing a double role now:
This presents all kind of complications if the user has two keystores on two different devices for the same account. For example, resetting the password on one device will, of course, not reset the password of the keystore on the second device.
Furthermore, the meteor password handling is a centralized part of our app - i.e. not in the spirit of what we want to to, and something to phase out in any case.
Proposal: use the keystore for meteor authentication
We could implement a system in which meteor identifies users by their Ethereum address, and users authenticate by sending a signed message to meteor.
This would imply the following flows:
Account creation
Password reset
Password reset is device dependent, and will create a new keystore only on the device where the password reset flow has been initiated.
Some previous discussion about this is in #105