WEBVTT

00:00.000 --> 00:04.620
>> Authentication: The
learning objectives for

00:04.620 --> 00:06.300
this lesson are to describe

00:06.300 --> 00:08.595
credential management
and password systems,

00:08.595 --> 00:11.175
and to explore a
federated trust methods.

00:11.175 --> 00:15.374
Let's get started.
Password policies.

00:15.374 --> 00:17.970
We've all dealt with
passwords and where we're

00:17.970 --> 00:20.250
told we have to use
complex passwords.

00:20.250 --> 00:24.345
This is how those complex
passwords are described.

00:24.345 --> 00:26.040
First we have
password length: the

00:26.040 --> 00:28.500
minimum or maximum
number of characters.

00:28.500 --> 00:32.070
Then password complexity:
no use of username,

00:32.070 --> 00:33.870
must contain upper
and lower letters,

00:33.870 --> 00:35.250
numbers, and characters.

00:35.250 --> 00:40.230
Password aging: select a new
password after a set time.

00:40.230 --> 00:42.510
Password reuse and history:

00:42.510 --> 00:44.565
you may not use
the same password,

00:44.565 --> 00:46.145
and then we also determine how

00:46.145 --> 00:48.550
many of those old
passwords are blocked.

00:48.550 --> 00:52.430
Character classes: we have
94 possible characters,

00:52.430 --> 00:54.620
26 upper, 26 lower,

00:54.620 --> 00:56.060
10 numbers, and then 33

00:56.060 --> 00:58.055
special characters
or punctuation.

00:58.055 --> 01:00.500
Finally, auditing:
this ensures that

01:00.500 --> 01:03.630
passwords comply
with our policies.

01:05.050 --> 01:08.600
Also, it's important
to know that we do not

01:08.600 --> 01:11.720
want to store our passwords
using reversible encryption.

01:11.720 --> 01:13.370
This is when passwords
are stored in

01:13.370 --> 01:14.930
a way that can be decrypted.

01:14.930 --> 01:16.520
This is a massive security risk

01:16.520 --> 01:18.720
and they should never be used.

01:19.330 --> 01:22.715
This is why strong
passwords are necessary.

01:22.715 --> 01:24.245
This chart gives us

01:24.245 --> 01:26.120
the estimate of how
long it would take to

01:26.120 --> 01:29.915
crack a password given
certain circumstances.

01:29.915 --> 01:33.215
On the left, we have the number
of characters from 4-18.

01:33.215 --> 01:35.360
Then going across the
top of the right,

01:35.360 --> 01:38.165
we have numbers only
lowercase letters,

01:38.165 --> 01:40.925
upper and lowercase
letters, numbers,

01:40.925 --> 01:42.710
upper and lowercase letters,

01:42.710 --> 01:44.615
and then finally, numbers,

01:44.615 --> 01:46.865
upper and lowercase
letters and symbols.

01:46.865 --> 01:50.135
You can see why it's
very important to use

01:50.135 --> 01:54.080
longer passwords that contain
everything from numbers,

01:54.080 --> 01:56.365
upper and lower,
and punctuation.

01:56.365 --> 01:59.120
Some of these can be
cracked so quickly that

01:59.120 --> 02:00.890
even a long password that is say

02:00.890 --> 02:02.990
15 characters long
that's only numbers,

02:02.990 --> 02:05.780
or 10 characters with

02:05.780 --> 02:09.755
lowercase n numbers
is only 58 minutes.

02:09.755 --> 02:11.600
It's very important to oppress

02:11.600 --> 02:13.490
upon users that they need to use

02:13.490 --> 02:15.560
longer passwords with all

02:15.560 --> 02:17.750
of the possibilities that
they could use: upper,

02:17.750 --> 02:20.580
lower, numbers, and
special characters.

02:20.810 --> 02:24.675
Instructor's side note:
NIST special publication,

02:24.675 --> 02:27.870
800.63b, has changed some of

02:27.870 --> 02:29.630
the passwords sacred
cows that have

02:29.630 --> 02:31.490
been used for a very long time.

02:31.490 --> 02:36.800
For example, password changes
and password complexity.

02:36.800 --> 02:38.780
What NIST is now saying is

02:38.780 --> 02:41.510
that strong method for
making passwords that

02:41.510 --> 02:43.760
users can easily remember is to

02:43.760 --> 02:46.205
take three or four random
words and put them together.

02:46.205 --> 02:49.130
For example, horse,
stove, and strawberry.

02:49.130 --> 02:50.750
This is 20 characters long.

02:50.750 --> 02:53.210
If we add some
capitalization, a number,

02:53.210 --> 02:54.800
and a character, we can make

02:54.800 --> 02:56.920
this password
nearly uncrackable.

02:56.920 --> 02:59.480
In fact, according
to security.org,

02:59.480 --> 03:01.100
this password would require

03:01.100 --> 03:03.590
200 sextillion years to crack.

03:03.590 --> 03:05.330
The reason NIST did this is they

03:05.330 --> 03:07.340
determined that if a
strong password was

03:07.340 --> 03:10.865
chosen upfront that met
these type of guidelines,

03:10.865 --> 03:13.040
it doesn't need to
be changed often,

03:13.040 --> 03:15.635
and it doesn't have
to be super complex.

03:15.635 --> 03:17.840
For example, the password here,

03:17.840 --> 03:21.395
horsestove@strawberry by adding
just a few changes to it,

03:21.395 --> 03:24.340
is very resistant to cracking.

03:26.210 --> 03:29.730
Privileged access
management: This

03:29.730 --> 03:31.880
protects against
credential theft

03:31.880 --> 03:34.195
and then also credential misuse.

03:34.195 --> 03:35.730
People, processes,

03:35.730 --> 03:38.270
and technology to secure,
control, monitor,

03:38.270 --> 03:42.665
and audit identities used by
people, services and apps.

03:42.665 --> 03:45.650
It also stores credentials
in a secure vault

03:45.650 --> 03:48.785
that requires additional
authentication to be used.

03:48.785 --> 03:51.440
Some examples of this
would be CyberArk,

03:51.440 --> 03:54.480
Beyond Trust, and Centrify.

03:56.650 --> 04:00.750
Federated trust
models: Federation;

04:00.750 --> 04:02.660
it's trusting accounts made

04:02.660 --> 04:04.835
and use by another organization.

04:04.835 --> 04:06.980
This allows these organizations

04:06.980 --> 04:08.720
to connect across each other.

04:08.720 --> 04:10.760
Example is using your Google ID

04:10.760 --> 04:12.790
to login to other websites.

04:12.790 --> 04:16.655
OpenID allows for a
single ID to be used by

04:16.655 --> 04:20.794
anyone in the participating
OpenID network websites.

04:20.794 --> 04:25.200
OpenID has authentication
to OAuth 2.0.

04:26.980 --> 04:29.735
Security Assertion
Markup Language,

04:29.735 --> 04:31.490
or SAML: This is

04:31.490 --> 04:34.040
a protocol for cloud
and network federation.

04:34.040 --> 04:38.375
Attestations or authorizations
are written in XML.

04:38.375 --> 04:42.335
Communications are
performed over HTTP/HTTPS,

04:42.335 --> 04:45.995
and simple object access
protocols or SOAP.

04:45.995 --> 04:48.215
Secure tokens are signed

04:48.215 --> 04:52.280
using XML signatures
specifications.

04:52.280 --> 04:55.445
Examples of this
would be Amazon AWS,

04:55.445 --> 04:57.440
the customers can access apps,

04:57.440 --> 04:59.660
and resources on the AWS

04:59.660 --> 05:03.750
without the need to
create AWS accounts.

05:05.570 --> 05:10.820
Federated trust models:
Shibboleth based on SAML,

05:10.820 --> 05:12.440
often used by universities

05:12.440 --> 05:14.510
and public service
organizations.

05:14.510 --> 05:18.245
The user contacts the
Shibboleth site via SAML.

05:18.245 --> 05:20.015
The site redirects to

05:20.015 --> 05:21.515
an identity provider

05:21.515 --> 05:24.445
that verifies using
SAML information.

05:24.445 --> 05:26.810
The identity
provider responds to

05:26.810 --> 05:29.630
the site with
authentication information,

05:29.630 --> 05:31.640
and then the site
validates and gives

05:31.640 --> 05:35.395
access based on the
user SAML information.

05:35.395 --> 05:39.165
Transitive trust: If resource A,

05:39.165 --> 05:40.785
trust resource B,

05:40.785 --> 05:42.510
and B trust C,

05:42.510 --> 05:44.160
than A trust C.

05:44.160 --> 05:48.060
A good example of this in
action is Active Directory.

05:49.490 --> 05:52.710
Security Assertion
Markup Language or SAML

05:52.710 --> 05:57.405
: We first start with
user accesses Salesforce,

05:57.405 --> 05:59.420
and then Salesforce redirects

05:59.420 --> 06:01.910
itself to Amazon
for authentication.

06:01.910 --> 06:04.235
Amazon authenticates the user

06:04.235 --> 06:06.695
and allows the user
to access Salesforce.

06:06.695 --> 06:11.160
This is a simplified
breakdown of how SAML works.

06:11.740 --> 06:14.900
Let's summarize what we
went over in this video.

06:14.900 --> 06:17.225
We discussed
credential management.

06:17.225 --> 06:18.680
We explained the importance of

06:18.680 --> 06:20.980
strong passwords and
password policies,

06:20.980 --> 06:23.030
and we discussed
the various types

06:23.030 --> 06:24.965
of federated trust models.

06:24.965 --> 06:29.045
Let's do some example questions.

06:29.045 --> 06:31.760
Question 1: This

06:31.760 --> 06:34.280
describes storing passwords in

06:34.280 --> 06:37.200
a way that passwords
can be decrypted.

06:37.900 --> 06:40.980
Reversible encryption.

06:41.000 --> 06:45.030
Question 2: Blank
is based on SAML,

06:45.030 --> 06:46.340
and is often used by

06:46.340 --> 06:49.530
universities and public
service organizations.

06:51.200 --> 06:54.975
Shibboleth. Question 3:

06:54.975 --> 06:56.750
Blank is designed to

06:56.750 --> 07:00.210
protect against credential
theft and misuse.

07:01.120 --> 07:04.500
Privileged Access Management.

07:05.600 --> 07:10.520
Question 4: which federated
trust method allows users

07:10.520 --> 07:11.930
to have a single account for

07:11.930 --> 07:15.450
all sides participating
in the same system?

07:16.190 --> 07:19.530
OpenID. I hope this video

07:19.530 --> 07:22.350
was useful to you, and I will
see you in the next one.