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.