What are the best practices to allow user signup and login for a dapp?

Question

From what I have researched, it seems that all of the methods for allowing a user to signup and login for an Ethereum dapp are very cumbersome for the user to use. What are the best practices to allow signup and login that match the following criteria:

1. The method for signup and login should not be cumbersome; ie: simple as normal methods of username/password or facebook and google oauth.

2. The method for signup should not charge the user any ethereum (gas) - taking someone's money just to signup would put off most people.

3. The method of signup and login should not make the user jump through hoops such as,
   a) entering email
   b) downloading a mobile app
   c) entering a wallet address
   d) waiting for authentication confirmation
   e)entering a code back on the signup screen, etc.

4. Extra software like MetaMask or Mist should not be required. (Maybe this is not possible?)

The goal here is to remove as many hurdles as possible to get users to the dapp.

Answer 1

AFAIK it's always easy and good to use the PGP key mechanism for user authentication in DAPPs built using Ethereum. It's possible to use the account address as the username and to let the user sign some data with his private key to verify. This article might help you in the process.

To make it easy for users, you can let users to store their private key on client's side (eg: embed it with app they use once registered etc. - make sure to notify user to keep the private key stored, if in any case app is uninstalled)

UPDATE : As discussed in the comments below, If you want to go for a traditional user account system use a traditional user table with usernames associated with an account address and to connect to the ethereum network use web3.js (refer this question) - However this is again going for a trusted third party mechanism.

Answer 2

Addressing #4, it's definitely possible, but you will have to make a decision between completely centralized vs decentralized approach.

MetaMask is decentralized (end users hold the private keys), but the the Chrome extension will require users to go through more hurdles to get started.

There are a bit more centralized solutions like Fortmatic which allows end users to directly interact with dapps on any browser without requiring downloading a Chrome extension.

There aren't a lot of traction current for dapps in general - I would rather opt-in for providing a better user experience and get traction for your app before considering adding decentralized approach as an option.

Answer 3

I know its too old thread but since I faced the very same problem I would like to answer it.

The concept of digital signature which blockchain uses, is very known tech but unfortunately it is not being used by normal people (i.e facebook user). Imagine an authenticator mobile app which has following functionality:

Components:

• An authenticator app
• Dapp server
• AuthServer

Registration:

• User goes visits the Dapp register page and scans a QR code which has a challenge string (generated on the AuthServer)
• A cryptographic keypair is generated using same protocol which blockchain use.
• User signs the challenge using privatekey and sends the following to DappServer: publickey, userdata, digitalsig (DS)
• DappServer stores users information and forwards the DS and publickey to AuthServer
• The user is registered

Login:

• User scans the QR code from the login page -> signs the message (the challenge)and sends the publickey, DS to DappServer
• DappServer verifies if user exists and then forwards the digitalSig verfiication request to the AuthServer
• The AuthServer verifies the DS and sends the response to DappSErver, based on that decision - a user is logged in.

Transaction signing:

• The transaction is formed on the Dapp and showns as QR
• User generates a new key-pair (this keypair can be generated using the same algorithm which was used for loginKeyPair generation)
• User scans the QR code and signs the transaction
• User submits the signed tx to DappServer which then submits to the network.

Note:

• Here as you can see, all of the Trust is on AuthServer but one can imagine the AuthServer to be a smart contract with just one method bool verifyDigitalSig(digitalSig, publikey) which is getter method.
• What we solved is, user does not have to pay anything just for login.
• This is login-first approach as oppose of wallet-first.

See if this helps.

Answer 4

You can use an Ethereum address as a unique identifier for a user account. You can then require the holder of the private key that maps to that address to sign a message which you can then check.

It is possible to verify that a message was signed with a particular private key without knowing the private key.

I wrote a blog post about signing a message a while back.

The problem with this approach is simplicity and community acceptance. I previously built a login protocol which worked as described above. The problem is that it either requires signing a message independent of your dapp (complex, barrier to entry) or the user providing their private key in some form (raw, key file, mnemonic etc) to your service such that you can provide the message signing.

When I did this the 'community' got angry because it was a security risk (were I a scammer).

TL;DR; It can be done but everyone will moan about security/decentralisation.