Remember a few posts ago, when I created a UserId property in our Activity model? Well, it's time to put it to use. Since I am not a mole person, I want to share my project with my friends and family, but it will make absolutely no sense if there is no indication of who created which activity. So I'll do what everyone does, let people sign up.

It will not look like that. Not because I'm a good designer, but because I don't have a front-end yet. For now, I'll continue using Postman to sign up and log in.

Before we talk about implementation and testing, let's go over what is under the hood when we talk about users. I'm sure you've heard of authentication, cryptography or even JWT. But what do they mean?

Authentication

Let's say you're trying to enter the FBI headquarters. The moment you try to go through, a security guard is going to ask you for your id. If you have one, he will look at the picture, look at your face and say: "Ok. You really are who you say you are.". However, if you don't show him an id or show him someone else's, he will not let you through. If you show an id that is not the official FBI Id, you won't get in and will probably be arrested.

It is basically the same on websites. You have to enter a valid e-mail and a password to prove that it is really you. There are other methods for authentication such as biometry, two-factor authentication (2FA) and third-party authentication (e. g. Login with Google). I'm not going to do that fancy stuff for now. Let's stick to the simple e-mail and password duo.

When I create a user, he will give me their email and password and I will store it in my database. When this same user wants to access my website, I'll ask for their credentials. If their email is not registered in my database, that means an account was never created with that e-mail. If they type a valid e-mail, but the password doesn't match the one in the database, I still can't let them in, because they don't have the right credentials. Only if the e-mail is valid AND the password matches the one stored in the database I can let this user in.

Cryptography

"Oh, gees... is he going to talk about Bitcoin?"

I am not. Have you ever heard of the P language? You basically add "p" before every syllable. So when you say "I have to go to the bathroom" as "Pi phapve pto pgo pto pthe pbapthroom" someone who knows the P language will understand the message, but for a bystander, you'll just be saying gibberish.

That's cryptography. You have the rule to encrypt the message and you have a way to read it if you have de decryption key. On the internet, this is very common. When someone sends a text to someone else it should be encrypted, so if another person intercepts the message, it's still impossible to read.

If the user's password is "il0v3H4rrySyl3s" I shouldn't be able to read it straight from the database because it is a huge invasion of privacy and sensible data. What if the user uses this password for their bank? So we are going to encrypt the password with something called HASH and store it encrypted.

The neat thing about Hash is that the encryption key is the password itself and there is no decryption key. And the result is a large string of characters tha seem completely random. For example:

SpinTrack	U8nqSmNNfb7aB48MrmDUvuL5myU
spintrack	9UjoAnZt0KJ9eresLULo28HypXM=

And you can see, that even the slightest change in the password will create a completely different hash.

"But if you can't decrypt the key, how will you know if the password the user typed is equal to the one in the database?" Simple. I encrypt the password the user typed the same way I did it the first time. If they match, the user typed the same password.

That is how I'll store my user's passwords.

That's enough for today. In the next post, I'll be talking about JWT and Cookies.

As always, if I've said something wrong or you have any suggestions, you are more than invited to leave a comment. Don't forget to stay curious!