This is an update on our #TwilioHackathon project progress - you can see the original post here:
Authentication
Because the software is going to be used by schools it needs to be secure - for this we wanted to ensure that not just anyone can access it and join any lesson! We wanted to set up accounts for students and teachers to ensure that only the students that belong to that particular class can access it.
Keeping passwords secure
Of course we didn't want to store the users password directly in the database, because if the passwords where stored in plain text, it would mean that if anyone, either an attacker or a developer carrying out maintenance on the database would be able to see exactly what people have set as their passwords and so the security of the system would be breached.
To overcome this we wanted some way of salting and hashing them. For this we decided to use Bcrypt - due to some previous experience using it.
As soon as a user creates an account, I use Bcrypt to salt & hash the password and then store the hashed version of the password in the database. Then once a user tries to log in we can use the Bcrypt .compare() function to compare the password the user entered with the hashed version from the database to authenticate them.
Handling User Sessions
As an extra layer of security, to ensure that users have been authenticated to use the applications services, the project creates user session tokens when the user logs in. To facilitate this, we decided to utilise JSON Web Tokens (JWT). Doing so ensures that no one can bypass login and access the services pages by changing the URL or hit the backend API directly.
Once a user successfully logs in, a session token is created for them and this token is sent with each request the user sends. Once the request is being handled, we do a check for two things - one, is the token valid and two, has the token expired. If these checks pass the request is carried out, however if it fails, a 401 error is thrown as the user is not authorised!
Top comments (0)