- [Instructor] In this lesson you will learn
the different authentication schemes in web applications.
So let's start by going over what is authentication
and what is session management.
Authentication is the process of verifying
that whether it's an individual an entity or website
is whoever actually is claiming to be right.
So, authentication is in the context of a web application
is commonly performed by submitting a username
or an identifier, you know an ID
and one or more items of private information like a,
you know, password, some key, some token,
some pressure key and so on.
Now, session management is how a server maintains the state
of an entity that is actually interacting with.
This is required for a server
to remember how to react to subsequent request.
Sessions are maintained on the server by default
with an identifier, with a session identifier.
And this session ID is actually passed back and forth
between the server and the client
when transmitting or receiving a request, right.
So session should be unique.
Of course, we know per user.
And also they should be computationally
very difficult to predict.
Now what web application scheme is a method or a recipe
to pass those credentials from a user
authenticating to a system, right.
So from the user to the actual authenticating system.
Now these schemes vary in their security and complexity.
Some of it can only handle authentication
and other ones can actually handle
both authentication and authorization.
Now, SSL or Secure Socket Layer
or TLS, Transport Layer Security
is typically used to ensure confidentiality
and that's actually a required prerequisite
for a lot of the authentication schemes to rely upon, right?
So, at the end of the day, nowadays,
all modern applications should be actually using TLS
and a strong version of TLS.
And we're gonna go into that later in the course.
Now, the following are some of the most common types
of web applications authentication schemes.
So we have TLS and, you know, of course, SSL.
And that is not only doing the authentication of the server,
but mutual authentication.
So that means authentication,
client based authentication as well.
And we're gonna cover that in a few.
Now, HTTP basic auth, is another one.
HTTP form based authentication is another one.
DAA, LTPA or Lightweight Third-party Authentication,
Oauth 2, OpenID, OpenID Connect and SAML.
Right, so those are the most
typical authentication schemes out there.
So let's actually start with TLS.
Right so TLS, a lot of people actually
refer to is as SSL, right support.
I do know there is modern versions of TLS,
so 1.3 and above,
is actually the central concept
of, you know, protecting it out
and authentication schemes, right.
So the central concept is in TLS
is actually the digital certificate
and how they actually form a chain of trust.
Now a digital or a public key certificate
is an electronic document that is actually pub,
approving or proving rather, the ownership of a public key.
The certificate contains details about the key
and the owner information and the digital signature
of a certificate authority,
who vouches for all the different contents, right.
So, now the digital certificates and certificate authorities
or CA's are central to public key infrastructure.
Right, now, every web client
has a default collection of certificates
from a major certificate authority
so your browser will have a list
of a collection of trusted certificate authorities.
That, are very popular there, right.
Now each certificate is actually signed
by a single authority and in turn,
the certificate of the signer
is actually signed by another authority,
each becoming white, more widely accepted.
Then finally the root certificate of the chain is self sign.
And it's widely distributed.
This root certificate is actually the anchor
of the trust in that PKR environment
is the public key infrastructure environment.
And that's actually used
to validate the entire certification tree, right.
Now, any certificate can be trusted
if it has been signed by a CA or certificate authority.
Now by far, the most common use of digital certificates
is establishing an SSL or TLS base channel of communication.
Now SSL authentication can take two forms.
Simple and mutual, but they also
people refer them as the one-way or two-Way authentication.
In one way authentication usually
is whenever an HTTPS connection,
right from your browser to a secure server
is established, right?
So in that case, actually,
there's a one way SSL authentication, if you will, right?
Because actually you're, the client
is verifying that the data Certificate of the server.
Now, if the certificate of the server is not found,
but the signed certificate
that the client actually does trust is found
then the client, she also trust the server.
You know, that's what we call the chain of trust.
Now, in mutual authentication,
everything that occurred in the first
you know, the one way,
you know, interaction still will happen, right?
So the, those nine messages are exchanged,
but they'll, also the server request the client,
to present a certificate
and to actually check it's sound collections
of trusted certificates to determine if it actually
can trust us the client.
So that's the concept of mutual authentication, right?
Now there's another method,
if you will, called TSRP, or TLS, secure remote password,
it was actually introduced as a means
to provide a password based
client authentication to a server
without the need of certificate.
It actually addresses the usability issues,
you know, managing certificate clients,
and you know, you don't have to actually worry about the,
the dual mutual authentication of certificates
and how they actually are,
are exchanged or maintained and everything else.
But typically, technically TLS or SRP,
was never widely adopted.
And it actually suffers from being you know, accepted.
So you barely actually use this nowadays.
But you know, just be aware that there's another method
called TLS, secure remote password.
So whenever you actually are doing your assessments
and your pen testing,
you may encounter some of these, right.
Now going to the traditional authentication method.
You also have the basic HTTP authentication, right.
So that's the integration actually,
you see in pop up messages from your browser.
There, hopefully they're barely used nowadays.
And they have no cookies, no handshakes
it's really basic authentication.
It actually uses a dedicated HTTP header
to actually communicate the encoded username and password
on every request that you use authentication.
So that requires the client.
So your browser, to actually cache the credentials
for a period of time.
Otherwise, the user will actually be prompted
to log in repeatedly, you know, every time.
Now since the credentials
are basically transmitted in the clear,
that's when you actually have to pair up
with SSL and TLS, right.
Now, it is simple to use
as simple to understand,
you know, you actually have
you know, those, I guess features
you know, for basic authentication,
or basic HTTP authentication,
but it has several drawbacks, right.
So there's no standard way to log out.
There's no way to customize the login experience.
The client needs to prompt users for credentials,
collect and encode those into the header.
And this is actually done by the browser by the way.
And then the client needs to secure the cache
credentials for a reasonable period of time.
There's also fundamentally, insecurity
as the full credentials actually,
are passing over the wire.
And that's the reason
that you actually have to put TLS on it.
But you know, again, hopefully,
you know, you don't encounter some of these.
There's many different problems,
especially in the implementations
and not not so much in, you know,
yes, that the technology actually has a lot of drawback.
But a lot of people actually have implemented very,
very young security in the past.
Now, there's also an HTTP form based authentication.
So in other words, you know,
an HTML form that is actually probably the most popular
form of authentication, you know,
because it's actually simple as well.
And it allows the login experience
to be completely customized
unlike basic authentication, right.
So this technique is actually simple,
like as I mentioned before,
basically just prompts the user for username and password
using a custom HTML form,
and then it sends those credentials to the server
in the next request.
So there's no standardization implementations,
you know, all of them are actually done ad hoc.
Now it requires, so these HTTP form based authentication
requires the use of SSL and TLS connections, of course,
definitely the credentials are gonna be sent
over the clear text.
So you don't want to do that.
Now, there's another format or form
called the Digest Access Authentication, or DAA.
And that was created to, you know,
to address the fact of basic authentication
since the full credentials to the server.
And in this case, DAA or Direct Access Authentication
only sends an MD5 hash to the server.
It actually includes some additional features
like a nonce and protection against you know,
anti replay attack.
However, you know, you gotta know
that MD5 is not secure, right?
That just access authentication schemes
within MD5 is considered insecure.
And this is because
it has a whole bunch of coalition attacks
that can be possible.
And of course, it's a weak hashing algorithm, right?
Now there's another method
called the Lightweight Third-party Authentication or LTPA.
And LTPA is actually not an IBM proprietary method
that was created to do single sign on, right?
It actually is, has to be used in conjunction
with another authentication technique
to initially authenticate the user.
And then once the user is actually logged in,
then the LTP, a token or you know,
the cookie is actually created.
Now there's another method, which is very,
very popular nowadays it's called OAuth2.
So of course, there's a processor, just OAuth.
But a strictly speaking, OAuth2 is actually
an authorization scheme.
In other words, you know,
before beginning the actual OAuth process,
the consumer application must first register
with the provided application.
And this is actually a manual one time process
that typically involves providing some basic information
about the application,
like the name, the website, you know, some logo,
you know, it all depends, right?
So there's also a redirect URI that can actually be used
for redirecting the user,
from the provider back to the consumer web server,
browser based or mobile app, right.
So all of them, you know,
actually use these type of technologies.
And that redirect URI
must be provided to prevent certain attack vectors.
Now the sequence starts
with a consumer making the OAuth2
resource request to the provider.
The provider application actually informs the user
of the requests and prompt them
to authenticate if they actually have not done so.
Now, the way that the provider authenticates the user
has nothing to do with OAuth2.
Any authentication schemes actually can be used
once the user is authenticated,
and has a granted permission permission
to the provider application,
the control reverse back to the consumer.
And that's actually done,
the other register redirect URI.
Now, you have actually accessed in an access token
that allows, you know,
the application to access the resources in the provider.
Now, this access token
is actually provided in the HTTP header
for subsequent request.
And the specifics of these interaction
between the consumer and the provider
depends on the, whether they're several,
the server hosted web sites, you know,
where browser based applications
or mobile applications, right.
So the each of them have their own implementation.
Now, what makes OAuth notable
is the fact that their users
credentials are never exposed to the consumer application.
The consumer is actually going to give in a temporary token,
that actually expires,
that's the reason that is temporary,
which can also be revoked by the user
or the provider application at a time
that you don't need those anymore, right.
So, and of course, that's what you actually see a lot
in the APIs nowadays, using OAuth2,
and if those tokens actually don't expire,
or for some reason the implementer or the developer,
you know, they put, you know, they expire it,
let's say for a year,
that is actually a very unsecure method.
So whenever you actually doing the pentesting engagement
and look at that, look at how the application is,
is whether expiring or not expiring, or you know,
how the actual, you know, credentials
are being exchanged or not exchanged
using these methods, right.
So not only OAuth2.
Now going back to OAuth2,
it actually mandates that you have to use dealers.
Now there's another method
that is also used at nowadays called OpenID.
And it's basically an open standard
for providing authentication of an identity.
There are many OIDs, identity providers out there.
Things like Yahoo, Flicker, Google, WordPress
and many others, right?
That they actually use OpenID.
Now, any client that outsources authentication
to one of these identity providers
are actually known to be the Relaying Party or the RP.
Now, the OpenID, the specification actually has
a set of extensions.
One of them is called the Attribute Exchange Extension
and it was actually done to profile attributes.
Like the name and the gender and you know,
some other identity elements
to be provided from the OpenID identity provider
to the Relaying Party, to the RP.
Now, essentially OID allows,
or OpenID allows a user to maintain a single profile
with an openID identity provider of their choice.
And also to authenticate with a third
any third party website, or where mobile application
that actually participates as a Relaying Party.
Now the last method that I'm gonna be covering
is called the Security Assertion Markup Language or SAML.
A lot of people actually referred to it as SAML.
It is an XML based open standard
that is maintained by OASIS.
It's actually used for
both authentication and authorization.
And it's also capable of exchanging
user profile attributes as well.
Now previous versions of SAML relied on SOAP over HTTP,
but newer versions you know,
so from version V2.0 and onwards,
it has a little bit more flexibility
because supports flexible bindings
and if exchanges are between the user an identity provider,
and the user and the service provider,
then SOAP is actually not necessary, right?
So SAML2 directs later, and the OpenID,
are actually different solutions to the same authentication
and authorization challenge, right?
So, now, SAML and OAuth2 can actually coexist.
Now nowadays, a lot of API is actually standardized in,
in using OAuth2, right?
So a lot of people actually use that.
And SAML is actually the current leading standard
for inter-domain web Single Sign-on or web SSO.
If you look at it, SSO, whether it's OpenID,
or a SAML for sure, those are the most prevalent ones.
In the case of modern API's, you see a lot of OAth2.
So whenever you're actually doing penetration testing,
one, become familiar with, you know, with those standards,
become familiar of how applications
actually may use them, may not use them, and so on.
And then later in the course,
actually we're gonna be covering several,
you know, techniques on how to
even test, you know, some of these modern applications
and what tools to use
and what flaws you can take advantage of
in your penetration testing engagement.