9

I was wondering how users will "sign in" to EOS. Users will need to share some private keys with the web app if the user wants the app to interact on its behalf with the EOS blockchain. I believe this is how steemit.com works.

EOS seems to have an advanced permission system, but I'm missing some guidance on best practices. I believe asking users to install an extension like Scatter will add a lot of friction, so I'm not considering it. Looking forward to knowing more about how this authentication & authorization mechanism will work.

Improve this question

4 Answers 4

Reset to default
14

I agree in parts when you say that asking to install an extension is a "lot of friction"... But we are dealing with real money here: the EOS Tokens. People want to feel protected. Majority of ETH adopters have Metamask.

It reminds me of the beginning of the internet where we should have an email to signup an account, and as people didn't like that, websites started to create the annoying usernames, that eventually turns out such a pain in the ass because you always forget. Now every decent service asks for email and people are fine.

Well I think we need to EDUCATE people. Blockchain is a new topic and there's no other way around. Imagine when it get real traction and every single website utilizes Scatter identities: https://www.youtube.com/watch?v=06RSj40bHhs

In a matter of 1 click you are logged in and most important PROTECTED.

In our project we are struggling about UX for a full new user signup flow: installation of Scatter, generation of keys, submitting it to our server to create and stake an eos account, make the user open scatter again and create a new identity... None of the stakeholders have liked it, so I'm working with a solution that we can improve a lil bit, trying to turn this process smoother...

But what I told them is that there's no other way around to get decentralized, people will really need to install a wallet to handle their accounts, does not matter if it's a desktop, mobile one, but honestly an extension like Scatter is amazing for that.

Unless you want to centralize and hold your users keys... Would you trust any app to do that? Or, you could even create an account for this app and only hold a minimum amount of tokens there... At the end you will end up with a lot of accounts (like usernames I mentioned above)...

Improve this answer
1
  • 1
    You are probably right that this is the way to go. I just like how seamless steemit.com is, although I agree with you that this is a problem when you have "accounts" on many sites.
    – Alex Gonzalez
    Commented May 14, 2018 at 12:52
2

You don't need to enforce people to use any extension.

You can generate a private key directly in the browser and store it its localstorage encrypted over a password with https://github.com/EOSIO/eosjs-keygen

When the user "logs in" to your app, it just is going to be recovery the private key back from the local storage. The key would never travel the internet.

When actually creating a new account for the user, you will send the generated PUBLIC key over to your server for signing the account creation transaction with your app's account.

In any case, seems reasonable to support people that has an existing EOS account and wallet integrating with Scatter.

-- EDIT --

For the question: what would happen if the user clears his localstorage?

You should always give them their private key and instruct them to store it in a safe place, and give the option to recover back from there by inputing the private key as a way of login. Additionally the accounts that you create could have your app account listed as 50% owner and you could instruct the user to set a friend as his account recovery with the other 50%, then he could recover his account completely even in the worse case by obtaining a transaction singed by both to "reset" his owner key.

Improve this answer
8
  • That's an interesting workaround, although it would be bad to tell users that they are screwed if they ever clear the browser cache.
    – Alex Gonzalez
    Commented May 14, 2018 at 12:55
  • but how are you going to sign transactions and interact with the application?
    – Leo Ribeiro
    Commented May 14, 2018 at 12:55
  • 1
    localstorage is not a permanent solution, if the browsers cache is cleared this will go too. This is why most methods involve some sort of browser extension. Either you'll have to ask them to back it up properly, which creates friction or rely on a more robust method.
    – altShiftDev
    Commented May 14, 2018 at 18:48
  • 1
    @altShiftDev, edited to add a comment regarding clearing cache.
    – Ariel Scarpinelli
    Commented May 14, 2018 at 18:54
  • 1
    Yeah. But that is a matter of trust and proper policy and communication. The private key must never travel the internet. For the case you also trust Scatter devs not to do whatever they want with your key. In any case I say that you should support it or any other competitors, just not lock in to it if you want to reduce friction
    – Ariel Scarpinelli
    Commented May 15, 2018 at 12:28
1

I would agree Scatter or a similar application would be the best practice. That said, it is undoubtedly going to cause friction for the end user. Maybe I am missing something but why not offer both options:

  • Authentication and Transaction Signing with Scatter

    or

  • Authentication via traditional Username and password

The second option could be achieved by generating a Keystore File (UTC/JSON) encrypted with the users normal password. The keystore file could be safely stored on the blockchain (or in any other DB) and used to recreate their Private Key each time the User authenticates. Furthermore if the user wanted to change their password in the future you could simply generate a new Keystore file associated with them.

This seems to be the way Scatter generates its backup file and the preferred way to authenticate in MyEtherWallet.

If people like this approach I will create an example and post to my GitHub

Improve this answer
2
  • Thanks for the idea. As I see it, you still can derive the private key from the password, so this is not really improving security. You still are trusting the web app not to do unwanted things with your EOS account. However, I see clear benefits in that the user needs to remember a password instead of an ugly private key and that the web app could be replicated and still be able to access the encrypted user credentials (since they could live in the blockchain instead of a traditional DB).
    – Alex Gonzalez
    Commented Jun 6, 2018 at 18:56
  • Yes, with traditional login the application can do unauthorized activity. However, that is the case with all applications currently. That is why I would advocate offering both options: Scatter for Users who value security and Traditional Login for Users who value convenience
    – Thomas55777
    Commented Jun 6, 2018 at 19:06
0

You can always handle the 'sign in' as usual, it need not be a on-chain authentication method. Your db can handle the correlations between usernames and keys. These keys would hold 0 tokens and they never have to be shared with the user either.

However this seems like a lot of unnecessary work when Scatter solves all of this. If you want to create the best possible experience, offering both of these solutions would probably be ideal, let the user decide how they want to handle authentication.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.