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 8.1.3.2, 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.