Hi everyone. In this lesson, we'll be giving an introduction to authentication. First, we begin with sessions as a RESTful resource, which includes being able to apply actions like create, read, update, and destroy on a session. Then we're going to talk about the idea of using web application frameworks to handle authentication and session management. Then we're going to talk about using cookies to allow for a state and sessions in our web applications. Finally, we will talk about general guidelines for authentication. By the end of this lesson, you'll be able to evaluate a system to determine if it follows a generally prescribed secure methods for authentication. Let's dive right in. So sessions can be conveniently thought of as a restful resource. REST is an acronym for Representational State Transfer. One of the ideas of REST is that each request from the client, the server needs to have all of the information needed in order to understand that particular request. The next main idea of REST is that requests are performed on a resource like a piece of data. For example, a file or the concept like a session. As long as the resource can be uniquely identified using an identifier. For example, using a URL. So with that in mind, you can think of a session as first with a login page, you would be forming a new session. So REST example would be to add this request of GET/session/login. Then, with the act of login, you could think of it as creating a new session. So a REST request example would be POST/session/login. Then with logging out, you could think of this as the act of destroying that session. So this REST example would be DELETE/session/logout. These REST request are HTTP requests. So when we think about authentication and session management, we might be tempted to create our own authentication session management subsystem. But we want to avoid doing that because logic and security issues could exist in our own authentication and session management subsystem. It takes time for these to be found and fixed. But with current existing web application frameworks, they had been previously tested and tried on production, and previous bugs have been fixed. These are convenient to use because web application frameworks will already have the plumbing for authenticating users and creating and destroying sessions. So for example, with the language of Ruby, you can use Ruby on Rails as a web application framework, and it has something called the has_secure_password functionality, which adds methods to your user model to set an authenticate against the password. When thinking about web application frameworks, you want to have certain criteria. At the very least, your web application framework should apply the secure and HttpOnly flags for the cookies they use. At the very least, that web application framework should set the domain and the path of parameters for your cookies correctly and at the very least, that web application framework should prevent session tokens from being included in URLs or accepted as URL parameters. Now, more detailed requirements can be found in OWASPs page called Cookie-Theft and Session-Hijacking. Now, when we think about Cookies and how they are used to create Stateful Sessions, there are common patterns that are used by web applications today. When they have logins and Session management subsystems. So one common pattern is for allowing of temporary sessions, and how this is done is that a temporary cookie is given to the browser from the server and here the browser forgets that cookie upon browser shutdown. The session ID is encrypted and is used as a data in the cookie. Now, with this functionality of having temporary sessions, it might not be sufficient. Maybe you want users to be able to be remembered by your web application even after shutting down the browser. So the way this is done is using this common pattern of using a So-called "remember token". So you can do this through an automatic remember functionality upon login, or be able to have the user click on a chip box like a "remember me" checkbox option when they first log in. The way this common pattern is done is that the server creates a "remember token" and this remember token is basically a random string of digits. It's a fixed length. The server stores the remember tokens hash digest in the back-end database. Now, note that I said that server stores the remember tokens hash digest, and not the remember token itself. So that's really key. Then the server sends to the browser the remember token as a cookie. Of course, over encrypted channel. Also, the server encrypts a user ID and that encrypted data is sent over to the browser as a cookie. So now, here, we have the browser having two cookies. First, the remember token and second, the encrypted user ID. Now, when the client comes back to access the web application, it gives the server the encrypted user ID and the remember token. Now, the server has these two pieces of data. First, what it does is it unencrypts the user ID, and then it goes and checks its back-end database to find that user ID. Then the next thing it does is it checks a client's remember token to see if it is the actual remember token that has been hashed in the back-end database. So if this hash matches the hash of the clients remember token, then the server knows that, that is the client with this particular session. So now, here are some general guidelines for authentication. Now, user ID should be unique and case insensitive or case-sensitive I should say and with passwords, you want to consider password length. According to nist SP 126.96.36.199, the minimum password length should be at least 10 characters. Anything below this is considered a weak password. Now, you want to consider password complexity. So you want to enforce the password having at least one uppercase character, at least one lowercase character, at least one digit, and at least one special character like an exclamation mark or a dollar sign symbol for example. Then you want to consider password storage. We're going to talk more about this in the last module, module four. But what I'm going to say now is that in order to authenticate using passwords, we would store the hash of the password concatenated with a salt. More specifically, in order to generate the salt which is random string, you want to use a secure random string generator or string function to generate this salt. Once you have that salt, you want to concatenate it to the password and then with a salt plus the password. So this whole string that's concatenated together, you want to put that through a secure hash like the crypt, which hashes the concatenated string. That hash output is what you would store in the database and not the plain text password. In other words, notice that we don't store the plain text password directly in the back-end database. So with login pages, you want to have it such that login pages and authenticated pages be accessed using TLS. So you want to make sure that communication between the browser and the web application on the server's side are encrypted, and you can use the HSTS header as we learned earlier. The next thing you want to make sure to do is to force the users to re-authenticate when the user is trying to access a sensitive feature. This is to make sure that we guard against session hijacking. Then another thing that you want to make sure to do is to implement some a lockout after a small number of unsuccessful authentication attempts. This is so that we can guard against brute force attacks So for example, guessing passwords. More authentication guidelines can be found in OWASP. So in summary, we talked about thinking of sessions as in RESTful resource, and then we talked about avoiding rolling your own authentication and session management subsystem. Instead, relying on web application frameworks, which already have this functionality. We talked about these common patterns of authenticating and remembering sessions. Then last, we talked about some general guidelines for enforcing certain rules for authentication. Thanks for listening.