Login system

[Nircek]

We should give users a possibility to register (depends on DB #19). My idea is to open registration only for invited users. There will be a hard-coded admin user and teachers team. Every team will have an assignee (by default who created the team) who can manage it. The admin can everything that teacher or a specific assignee can. The admin is the assignee of the teachers team and can change assignees of all teams (except teachers one because it's hard-coded). Every teacher can create a team (like a class in school), and a student can register by joining one (and only one). The assignee can open and close the invitations to their team. The invitation is just a random (or specified, it can be useful for public) 6-digit invitation code. During the registration, the user has to enter the invitation code and then, the assignee has to accept them (or disable individual checks in team's settings). Should the code changes after reopening the registration? We can store the last invitation code and ask the assignee if it is good. Or fill the input box by default, it will be better.

[Nircek]

All students log in by using their mail and password. During the registration, the user provides an e-mail, password, id number and invitation number. Invitation codes contain 8 characters.

[Nircek]

@MichalTheProgrammer, you asked if we want to use the OAuth. I think it's a good idea.

Besides, I think if someone tries using regular registration, we should protect the server via a sort of CAPTCHA or reCAPTCHA.

We need to include all of this in the API (#25 or later). The question is, do we want to make this in v0.2 or let it remain the issue for the future?

[MichalTheProgrammer]

I don't think we need it right now. I would rather think about it as an improvement in the future.

[Nircek]

Okay, I think the most important thing about this site is the security of plaintext passwords themselves.

Why? Because it's easier to steal the not encrypted packets than break into the server and apply malicious code. Naturally, I am assuming that the database is secure by server-side hashing.

So my idea is to hash the passwords before an authentication. We can use the HMAC-SHA512 variant of the PBKDF2. The password is undeniably the user's password, and as the salt, we should use a login (an email or the hard-coded username). The 1.000.000 iterations and the obtained key with 256 bit-length ought to be secure. Then, how can we pass the binary hash over JSON in API? We can use the Base64 encoding.

I have written a sample implementation in JavaScript here. You can calculate the hash of the password secret and the username admin (YWRtaW4=), and the result should be the "u/+1fh/AmmWzro+YA7khgk1L5VfYoABocupuT41i+AA=" string for any implementation.

[Nircek]

As I wrote in the API, there is always the hard-coded admin team with id 0. It isn't possible to make an invitation code for it, so one can't register an admin user through API.

[Nircek]

The username admin was changed to root and you can access it with the use of .env file.