Hello, and welcome to secure JavaScript programming with Vladimir de Turckheim. I'm Vladimir de Turckheim, I am the lead engineer at a start-up named Sqreen, where we do web security. And I'm also a member of the Chrome Node.js team, I've been having node.js Chrome for a few years now. You can follow me on twitter, that's actually my preferred way of being contacted over the internet. So if you want to reach out directly, feel free to do that through my twitter account, it's @poledesfetes. So in this course we will talk about authentications and the flows and the vocabulary linked to authentication. And we will mostly focus on web applications of course. So first what is authentication, authentication is the act of knowing who is the current client and there can be multiple kind of clients in an authentication flow. It can be a human being, a real user. So you want to identify who is the human being on the other side of the network. There can be a device you want to identify that it is a phone or a computer that is doing the operations. If it's my client a device or maybe a piece of software, you want to identify a piece of software such as a web browser or if you have a licensing server, you would identify as a piece of software on the other side of the network. And that's pretty much the idea of authentication, you want to identify who is the client. But depending on the context, they can be different kind of entities. When you want to identify a client, you usually do what's called a login operation, a login action and that the act of identifying client based on shared secrets. So multiple secrets or traits, so you have multiple ways of doing that. And usually once you have done the login, you create what's called a session, which is at lateral. So you have multiple ways of identifying someone with secret. Either you have shared secret and that's actually not really strong because if to identify someone, I just need to know a password we both know. There are too many people who'd know this passwords, so that's probably good for spy movies but that's not really able on the internet and on networks. You can use a couple username/password. In that case you need to hash the password, so you don't know the password on the server site and only the client knows the password which is at lateral. You can use OTPs for One-Time Passwords, that's the kind of password you get by text message or on an authenticator application on your mobile phone. In that case I would recommend you use a third party provider because the specification to build OTP systems is actually pretty complex. There is a RFC for that and it's really complex and it's really easy to make a mistake and reduce the security level of the world system. So I would advise against rolling your own. That's been at least our third party logins, that's for instance our social logins, where you login through google or login through Facebook. Well, you rely on a third party to handle the authentication of the user. You can also have commercial entities, that's what business uses to do authentication and user management for you, one of them for instance's Auth0. Well login usually happens occasionally, you don't login to your gmail email address every day. You have your browsers that is authenticated to against it and usually end user is aware of it because there is a user action. If there is a password to write, the user has to write the password. If there is a one-time passwords, they have to get it on their phone. If that's a third party login, well they have to click on login with the third party. So the end user are human being is usually aware of these operations. Once you've identified what's on the other side, you can create a session. And session, it's to identify your client that is already logged in. There are multiple ways to keep a session and basically the idea is that for each HTTP request you are able to know what is with the client on the other side without asking for the end user to write a password for any HTTP request. So there are multiple technologies and as for login, you can use more than one at the same time. So for instance, one of the most popular one is cookies. Please only have them overlay HTTP and don't make them accessible. To the JavaScript code, you've got the JSON web tokens or JWT. Don't say JWT token because it stands for JSON web token token and it doesn't really mean anything and that's a mistake a lot of people do. So for instance, JSON web token, I will weigh two data in a signed way. So you know who issued the token because it's signed and with the public key, you can check that it has been signed by the authority you expect it to sign it. But it can make sense to use a JWT as a cookie, there is nothing preventing that, that's actually pretty common. Or you can just generate a random string, sign it to make sure that it has been issued by your trusted authority and put that in a cookie. That would totally work, and that's the most usual way of authenticating a user on the internet. The end user doesn't know about that because it's under the hood. Because at HTTP request the cookie that is in the browser is sent back to the server and the server maps in database with the cookie and the user account. So a few best practices here, only do this over HTTPS. Don't do that over HTTP because if there is no encryption on the way, anyone can steal a session. Also you need to expire sessions, at one point a session cannot be valid forever and you need to invalidate session. So if someone logs off, logs out of the service, you need to make sure that the cookie, the token is not valid anymore and will refuse to authenticate on each request. That's a very common mistake of the web to forget to invalidate sessions. Okay speaking of logout, logout is the act of closing a station. So you need to invalidate it, it must be done. Once again, it's a very common mistake. Everyone forgets about logout for some reason. Sometimes it makes sense to have a logout on the app, even on a mobile app and that's a project choice, it has to fit in the user experience for your application. Usually you want the user to be aware of that, so they actively logged out. So for instance, if you're checking your bank records online, you want to make sure that you logout before anyone else can use the same browser. Or even you want to logout to invalidate your decision, so if anyone is able to find your cookies in log, they cannot replay it. That's why it's extremely important to logout from your bank record online. However, it's possible that decision is just invalidated, expired, and if it's just expired, well, you're silently logged out and you will discover that when you have to login again. Authorization, authorization happens when a client try to access a resource. And when you try to access a resource, you need to make sure that the client has the right to access this resource. So there can be multiple level of authorization. For instance, if you've got a system that is full readily, better only for authenticated user. You just need to check if the user is authenticated and that's enough. But if that a personal record, let's say that's where a school keeps the grade of the student. You don't trump student A to have access to the grade of student B. So there's this student, does the resource contain data must not be sent to these clients, that's the third bullet point here. Also there is the question of role, if you're an admin on the system, maybe you have access to all the data inside the system. So there is a question of authentication of ownership of the resource and rights as role based access. Where admin has access to everything, moderator can moderate data and people can just access the data as it makes sense for them, for regular users. So content-based access is really important because in the GDPR and CPA based world, the content of a resource might be extremely sensitive. Well for instance, if you have a social security number or a bank account balance in your system. You need to make sure that the user accessing to that has the right to access it. Maybe some employees of the bank must not access Social Security Number of some clients. So when fetching the resource, one must know if the PII, that's Personal Identifiable Information of an individual can be accessed by his client. That's the needs from the GDPR. An example, a person delivering parcels should not have direct access to the phone number of the customers. This must go through a central service guaranteeing anonymity of the phone number to both party because It's a two way street. If someone delivers a parcel to you, you should not have access to the personal phone number of the delivery person. And if you check the history of car sharing applications. There have been a lot of cases where the driver having Personal Identifiable Information about passengers could lead to issues. And that's why you need to guarantee anonymity between those two parties. So check your PIIs, that's one of the most important part. Let's go for this last part of this course, which is cryptography for the busy dev. This is in no way across about cryptography, much more refreshers on what basics of cryptographic concepts must be known by anyone building web applications. So hashing functions, I like to say it's how to check a secret without knowing it. Password hashing functions are used to check passwords without selling them at plaintext. Basically, you give a string as input to this function. Whatever it lands and it will return a fixed-length string and guarantee it's really hard to find two outputs with the same output. So you pass a parameter, you get a response and output. And it's extremely hard from the output to find the input, and to find an input that gives you the same output. How do you choose the right hashing function? Well, I will recommend checking with the National Institute for Standards and Technology, the NIST recommends. Because this evolves with time as knowledge and attacks evolve against these functions. So to be up to date, check what the NIST recommends. Also be sure to use a salt to avoid kind of attacks that can be time attacks or rainbow table attacks. And feel free to google in-depth what it is, but this is not a course about attacking cryptography, so I won't go in depth with that. Usually bcrypt is a safe bet. Symmetric cryptography, there's a single private key and both party knows it. So that's when you have a shared secret, there's only one secret and it can be used to cipher and decipher the message. So you have a message, you used the key, you can cipher it and you use the same key, you can decipher it. This is usually very very good in terms of performance and the standard algorithm right now for that is AES, it's a very good algorithm for that. It use a private key, but it's a blog algorithm so it can lead to certain attacks against it. Wikipedia is really good at explaining what they are. So when you use that, use an operation mode to turn it into a stream algorithm where the block attack can't happen. Asymmetric cryptography on the other hand is really interesting tool. You've got a private key, that's a secret known by a single entity and there's a public key that everyone in the world can know. And if you cypher the message with the public key, only the person that have access to the private key will be able to decipher it. Also you can use the private key to sign a message, and in that key everyone with the public key will be able to ensure that the message was signed using that private key. So that's the signature because you can identify the author of this signature. One of the most popular asymmetric cryptography is RSA, you also have BGP. Overall and that's probably one of the most important slide in this world presentation, never roll your own cryptography. So there are countless of cryptographic algorithms, some of them are really complex to implement. Most of them are really complex to implement. And don't take us back on implementation on cryptography. Always let someone do that for you because this is actually really hard to do and really easy to fail. Thanks so much for watching this presentation. I hope to see you soon in another presentation about JavaScript Secure Programming. Until then, have a great day and take care.
