Introduce alternative sign in mechanism based on message signing

[kelsos]

Abstract

This is a matter we have discussed this matter with @LefterisJP a couple of times before.
Currently, you can use your passphrase/password for an account but that passphrase is something you have to remember since this is the encryption key of your database.

If you somehow lose access to the passphrase there is absolutely no way to recover it.

The discussion we had was to provide a way to provide a derivative key/password that gets created by signing a message with an Ethereum account.

This way we could provide a mechanism where you could log in either via Metamask or WalletConnect.

Tasks

• We have to think of any possible problems or limitations of this approach.
• Provide an onboarding/offboarding experience where the users can switch between the two authentication schemes.

[A2be]

I have no problem with this sort of a feature enhancement, but I do think it would definitely need to stay only an optional second way to sign in to Rotki?

Why? Because using my web3 credentials to sign in to my Rotki would mean I could not share my Rotki DB and DB encryption key with my tax professional, so that we together can take all the wonderful stuff that Rotki pulls together, and get it into a jurisdiction-specific tax accounting for preparing input to the tax authorities.

[LefterisJP]

yes this would be optional.

[kelsos]

Optional, and while you should be able use one way or the other to login, we should also provide a way to move between the too.

[A2be]

Creative idea: might we be able to take, say, @A2be's public web3 ENS-address into account (say a hash, or other creative thing smart cryptographically-knowledgeable devs will come up with) as a PART of my Rotki DB encryption key.

That way, perhaps the Rotki user could still

• "sign in" to Rotki via web3,

but ALSO

• have a share-able DB encryption key that they might provide their tax professional to use with Rotki and the user's Rotki DB for doing tax analysis and getting the jurisdiction-specific tax stuff in order?

[lukicenturi]

So this is what I understand at the moment.

So when the user wants to register, they still need to type the username they want.
Then for the password, they can type manually, or generate the password by signing a message with an ETH account.

After the password is generated, at least we should show the generated password once to the user, so the user can keep it or save it on their password manager. (If somehow the password generated later is don't match)

It's also same for login where user can choose to type in the password manually, or by signing a message again.

Am I right? @kelsos @LefterisJP

[A2be]

@lukicenturi , I think it is important that SignInWithEthereum (SIWE) not force the end user to use the old web2 username construct.

However, I think we could use a part of whatever is generated by the signed-Ethereum transaction+EthAddress as a DB name for the DB name / Encryption key pair that is used today for one use case. That is the case where a user wants to share their Rotki DB with someone, say their tax professional who is handling crypto tax accounting for them.

This was what I was trying to get at with this previous comment:

Creative idea: might we be able to take, say, @A2be's public web3 ENS-address into account (say a hash, or other creative thing smart cryptographically-knowledgeable devs will come up with) as a PART of my Rotki DB encryption key.

That way, perhaps the Rotki user could still

• "sign in" to Rotki via web3,

but ALSO

• have a share-able DB encryption key that they might provide their tax professional to use with Rotki and the user's Rotki DB for doing tax analysis and getting the jurisdiction-specific tax stuff in order?

[LefterisJP]

@lukicenturi , I think it is important that SignInWithEthereum (SIWE) not force the end user to use the old web2 username construct.

However, I think we could use a part of whatever is generated by the signed-Ethereum transaction+EthAddress as a DB name for the DB name / Encryption key pair that is used today for one use case. That is the case where a user wants to share their Rotki DB with someone, say their tax professional who is handling crypto tax accounting for them.

This was what I was trying to get at with this previous comment:

Creative idea: might we be able to take, say, @A2be's public web3 ENS-address into account (say a hash, or other creative thing smart cryptographically-knowledgeable devs will come up with) as a PART of my Rotki DB encryption key.
That way, perhaps the Rotki user could still

• "sign in" to Rotki via web3,

but ALSO

• have a share-able DB encryption key that they might provide their tax professional to use with Rotki and the user's Rotki DB for doing tax analysis and getting the jurisdiction-specific tax stuff in order?

if you want to share the DB you need to share the actual file. Sign in is not related. But yes the username in that case can be something like the address alone.

So when the user wants to register, they still need to type the username they want.

If it's a new account I would say we do something like what @A2be suggested. By signing in both username and "password" are made automatically with the sign in with ethereum method.

For old accounts we should allow the option to change the password to ethereum message signing so you associate the sign in to the DB with an ethereum account.