[Proposal] Users

[jschr]

Why?

For accountability and security, most features require some sort of user context. A user identifies which actions are allowed to be performed on behalf of the client.

For example, features that would require a user context are:

• Commenting on proposals
• Saving meta data like masternode keys and using them to vote on proposals
• ... (See README for upcoming feature roadmap).

What?

Users will need to:

Create an account

Required fields for creating an account:

• Username
• Password
• Confirm password
• Email?
• Captcha?

Email, Captcha and PINs

DashCentral requires that the user fills in a Captcha. I'm assuming they do this to avoid spam and bots:

I'm assuming because they don't require that the user provide an email, they instead require a PIN. The user is required to remember and re-enter the PIN whenever they make an account change. I'm curious as to why they felt the need to have the extra security.

Requiring a PIN and Captcha seems to be the natural tradeoff for anonymity (at the cost of convenience).

Advantages to requiring an email means we likely don't need a captcha to prevent spam / bots or a PIN for account changes. We could also leverage a magic link to be sent via email instead of as password, simplifying the login process.

If our users are expected to be the same as DashCentral users then in may make sense copy the experience. However, Slack seems to be a popular gathering ground of our user base which requires an email and allows magic link in addition to password auth.

Login

Required fields for login:

• Username (or email)
• Password (or magic link)
• Reset password?

Account settings

Required fields for account settings:

• Email?
• Timezone?
• PIN?
• API Key?

Compared to DashCentral:

How?

Users will be able to register with a username / password. They can optionally provide an email for password resets. If an email is entered a confirmation email is sent. To prevent spam a captcha is required.

Even though username / password login is fairly trivial I think we would benefit from using a lib like http://passportjs.org/ for future authentication strategies.

For captcha, I suggest ReCaptcha by google: https://www.google.com/recaptcha/intro/android.html

Database

Table name

users

Schema

id: int (auto-increment) username: string (unique) password: string (bcrypt) email: string (unique, nullable) emailConfirmationHash: string (nullable) emailConfirmed: boolean ... other fields that make up a user profile?

API

POST /v0/login { username or email, password } -> auth jwt POST /v0/users { username, password, email? } -> new user GET /v0/users/self -> verify jwt -> user profile for jwt.sub (username, email, ...?) PUT /v0/users/self -> verify jwt ->{ email? } -> updated user for jwt.sub

[TODO]: Password reset

[jschr]

@KristerV Have you put anymore thought into user session?

You have a better idea of our typical user base than I do but it would seem to me that using email / magic link would be the most convenient and would potentially simplify things for us (not needing captcha or PINs).

It seems like our user base is pretty ok with logging in with email (ie. Slack) and they will need to provide an email anyways to reset passwords (ie. DashCentral).

Unless I dont fully grasp the security concerns, it doesn’t seem like we are storing any coins or sensitive customer information that would benefit from an anonymous, email-less login.

[KristerV]

So here are the results of the questionnaire:

So about 20% people don't want to give an email. Considering that large MN owners may not even be in the chat and we need their support then well we got to go with no-email. The sensitive information we need to protect is who owns masternodes. Some people don't want their wealth to be public. And by public I mean hackable.

An extra thing to consider is that there are 3 types of users:

1. Masternode owner
2. Proposal submitter (may not have masternode)
3. Just some person.

Since only masternode owners can vote type 3 doesn't even have to have an account, really. Once I figure out how proposal submitting works exactly we could perhaps create system where you can only get a user if you have masternodes. And type 2 can perhaps submit without account (this is possible anyway) and claim the proposal and get account with the same process (since submitting requires 5HLM payment).

So that means

if (masternodeOwner) { registerUserEasily(masternodeKey) }
if (myProposalSubmitted) { claimProposal && getAccount }
else { throw Error("You have no reason to be here") }

[jschr]

Can a single user have multiple master node keys?

Updated the How section, let me know what you think. Do you have a preference between snake_case and camelCase for db columns?

If ReCaptcha sounds good to you I think you'll need to set it up as the domain owner: https://www.google.com/recaptcha/admin

[KristerV]

1. yes, a single user can have unlimited masternode keys, but on average under 10.
2. Nope, don'tMind_either.
3. ReCaptcha. hmm. I wonder if there's another way. I'm under the impression that what we need help with is stopping the random web crawling bots. For this we could just use timestamp analysis and honeypot. This leaves open the bot that is manually programmed, but I really don't think that's a problem. So perhaps we'll deal with that when we see abuse? Like the worst thing someone with a manually programmed bot can do is spam or vote with their own masternodes. Assuming they haven't hacked other people, but that's a whole other issue.