[Autogenerated] now where requirement 8.1 was
concerned with the user IDs or accounts.
Requirement 8.2 is concerned with the authentication of the user.
On the core requirement is that at least one authentication factories needed.
It's really important to note that this is one of those requirements that
doesn't apply to users who process one card at a time,
for example, in that retail setting.
But to those accounts that the requirement does apply to
Requirement 8.1 says that along with the user ID,
a user needs to authenticate themselves with one other factor,
which could be something the user knows,
like a password, something the user has,
like a token or something that the user is like a
biometric fingerprint or something on.
To test this, the QoS A will look at the system documentation,
then also watch users logging on on observe them,
using their authentication factor in really simple terms,
this requirement says, have a password with a username.
But it says have second authentication factor,
so it might not necessarily be a password,
but the 90% or 95% of occasions this is I have a
password with your username requirement.
The next requirement is concerned with the security of
passwords that used the authentication factor.
They have to be encrypted at rest and in transit with strong
cryptography on Before we look at the actual words of the standard
reminder that the term strong cryptography is defined in the PC IDE
CSS glossary as being based on industry tested algorithms with the
least 112 bits of K strength.
So that's at least triple days.
Probably nowadays,
that's probably a yes 1 28 where for a symmetric cipher and
2048 bit are safer in asymmetric cipher.
The actual requirement is very simply written that this
strong cryptography has to protect passwords and pass
phrases at rest and in transit.
Now just a very quick thing.
But of course, most people never encrypted password.
You're going to use a one way hashing function on compare the hash of the
password the user types in with the hash that you've got stored and again
that strong cryptography means you're using a hashing function that's
regarded by nest as a strong hashing function.
So the actual requirement there's simply written,
but strong cryptography has to protect passwords and
press phrases at rest and in transit.
Now, this is quite hard One for the QoS SATA test,
the one that can cause lots of arguments.
There are three parts the written testing procedure.
Firstly, to verify that strong cryptography is used,
the QoS a has got to check vendor documentation.
So the vendor specifies the algorithm and key size used the QoS.
A has to talk about his face value.
Next,
the QoS is supposed to check password files and stiff network
transmissions to make sure they can't see clear text password.
That's what they're looking for.
Clear text passwords.
Because the standard assumes that if the
documentation only configuration settings,
you can see,
say or indicate strong cryptography and the passwords error
obviously encrypted at rest and in transit that that strong
cryptography is being used.
The use A doesn't have to test the strength of the cryptography themselves.
And if they try to,
you need to point them at the exact testing procedure in the standard.
Because I have seen QoS a really go to town on this requirement.
So Well, I'm gonna try and look at the cryptography using going to.
Try and break it That's not what their job is in simple terms.
The next requirement wants to make sure that when an
authentication credential such as a password is reset,
the person or system actually doing the reset actually checked the user.
Requesting the password to be reset is who they claim to bay,
not criminal pretending to be somebody.
So this obviously aims to prevent a social engineering attack where the
criminal maliciously resets error user's password on,
then gain access to that user's account.
This is still a very common way for criminals to attack,
so that need to be documented policies and processes in
place to prevent it happening on the QoS.
A will want to look at these policies and procedures that will also watch
what happens when a user requests the credential research.
The next requirement, in 8.2 point three is concerned with password complexity,
and again it, along with the next two requirements,
is one of those that doesn't apply to people who
process a single transaction of time,
such as retail people operating upon its sale system.
Now, in today's terms, PC IDE CSS is complex.
Requirement isn't hard to meet because it just requires a minimum of seven
characters and just a mix of alphabetic on numeric characters.
In the password, you can use an alternative set of password rules.
Different lens, different character sets.
If you want a zlotys, they've got the same complexity.
Is PC IDE CSS So the QoS is going to look at where password
complexity is defined in the system configuration.
Now, of course,
related to password length and complexity is how
frequently passwords error changed.
API C# CSS wants us to happen.
Wants every 90 days at a minimum.
Now the good news is you don't have to have a Q S A on site
for 90 days to make sure this happens.
When they do the testing.
They're just going to check how the system's error configured.
Now look,
if you're thinking that PC IDE CSS is desire for low complexity
passwords that have changed every 90 days runs contrary to all
modern advice from this on the U.
K s National Cybersecurity center, you're absolutely right on.
This is addressed in a fake.
It's a fake number 1467 which confined on the P CSS See website.
The short summary of this that it's okay to go for longer,
more complex passwords with less changes if you documented in a
compensating control and follow the NIST or en CSC guidance.
If you want to read the whole EFC, then head on over to the P CSS3 website,
click on EFC at the right of the menu and just
typing the number you're looking for,
which in this case is 1467 Then what you need to do is click on the link,
and then you can read the POCO itself, still with passwords.
PC IDE CSS also wants to make sure that users don't reuse passwords.
And so requirement 8.2 point five is that the last four
passwords or pass phrases can't be reused again.
The QoS A will test this by looking at system configurations,
not by asking someone to make lots of password changes.
We've reached the last password related sub requirement,
and this is one that actually causes organizations lots of problems
because it wants to make sure that when a password is initially
allocated to a user that that's a unique password that's not been
users initial password to any other user before in the history of
time at the organization.
And so,
as well as requiring a unique first time Passover for each
user account that's created a reset.
The user also needs to be forced to change that
password the first time they log in.
I mean, this is a pretty straightforward, in common sense requirement.
But of all the PC IDE CSS password requirements,
this is the one I've seen cause most problems in organizations,
because the service desk really has a problem thinking of new unique passwords.
So my tip is to give them a non technical book,
you know, a work, a work of fiction.
Have them open it a random place on,
then just picked to random words next to each other,
then get them to look at the clock and upend the current
minutes past the hour to the two words they've picked on
that will give them a random, unique password.
To test this requirement, the QoS A will observe how initializer,
or password resets passwords are set to a new value and also want to see
that tick boxes checked in the system configuration to make sure that the
user has to change their password when they log in