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.