Welcome back. Today we're going to briefly chat about
the OWASP Proactive Controls
that are related to sensitive data exposure.
This is basically a wrap up of what
we've been talking about in module four,
and tying it back to
the OWASP proactive controls that are
related to sensitive data exposure issues.
At the end of this lesson,
you'll be able to explain how
OWASP proactive controls are related to
sensitive data exposure. Let's get started.
Now, with this module,
we see that there's two controls that basically apply,
and there's an overlap with the module that
is related to broken authentication,
and session management here.
The reason why this module's proactive control
slightly overlaps with a module related to
broken authentication and session management is
because of the fact that it is possible to store
information related to passwords incorrectly.
For example, if you've already
read the extra readings from module four,
we saw in real life that there was an issue of storing
plain text passwords with vk.com.
We also saw the password related information.
For example, the hash of
passwords can be generated in such a way that they are
fairly weak as was the case with mall.cz.
One way to mitigate this issue is
to setup multi-factor authentication.
In other words, two FA with
onetime tokens like Duo or Google Authenticator.
Now, we have here
specifically the OWASP Proactive
Controls for Sensitive Data.
It's control eight which is to protect data everywhere.
What we need to do is to classify
our data based on their sensitivity levels.
We also mentioned in module four that
we need to encrypt our data in transit,
and at rest, and we want to make
sure to keep application secret.
In control six which is that overlap that I
mentioned earlier with
broken authentication and session management,
we want to think about whether we want to use password
only authentication or use multi-factor authentication.
Sometimes with the web application that you develop,
maybe it's good enough to
use password only authentication.
However, you might want
to consider the data that they're sensitive,
and their sensitivity levels,
and then think about whether you
really need multi-factor authentication.
There are times when that is
actually a really good option to do.
Now, to summarize the mitigations
that we mentioned in module four,
we mentioned that we want to
generate session tokens that are hard to guess.
We want to generate and use password,
or use proper salt,
and a secure slow hash function like bcrypt,
or PBKDF2 for hashing the password,
and store the hash of the password
instead of the plain text password.
Also, store the salt that is associated
with that hash along with a user ID etc.
We also mentioned that we want to use HTTPS between
the client and the server in order to encrypt
the HTTP communication between the two.
That's it for now. Thanks for listening.