Learn about how attackers typically don’t break crypto directly. They break something else, such as steal keys, do man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user’s browser.
- [Narrator] The third item in the OWASP Top 10 is sensitive data exposure. The basic idea is that sensitive data should always be encrypted so that it cannot be viewed in plain text. Even in cases when sensitive data is encrypted, hackers can often take advantage of mistakes in how the cryptography has been implemented. In this section we'll talk about classifying and handling sensitive data, how cryptography works at a very high level, and a few of the most common mistakes that can occur when trying to encrypt sensitive data.
When it comes to security and risk management, I like to say that there's no need to put a $200 fence around a $5 asset. Different assets have different values and should be protected accordingly. Data, of course, is a kind of asset, and different data types have different values in the context of a web application. It's important that data be classified or put into categories according to their type so that they can be protected.
Some examples of typical data classification categories include regulated data, confidential data, internal data, and public data. Information like credit cards and Social Security numbers should always be protected, but publicly available information doesn't require the same level of security. The first thing to consider when it comes to sensitive data exposure is whether or not sensitive data needs to be collected, processed, or stored in the first place.
If you don't have it in the first place, then it can't be stolen from you. An example scenario involves an ecommerce application that needs to process payments. The designers and developers for that application might decide to custom build the payment mechanisms, in which case they would probably need to collect and process some credit card data. Alternatively, they could decide to use something like PayPal or Stripe to handle their customer payments, in which case their application may not need to handle credit card information at all.
Say you've decided that your application does indeed need to collect, process, or store some sensitive information. A good way to protect that information from hackers who might access the data is by encrypting it. Encryption is a process that applies a mathematical algorithm and an encryption key to regular text, turning it into a format that can only be read by someone who knows what algorithm was used and has a proper decryption key.
The thing about cryptography is that it's pretty complicated to do right. This means that it's easy to make a mistake that a hacker might be able to take advantage of in order to read the sensitive information. The two most important things about any encryption technique are the algorithm and the key. Proper protection of sensitive data requires a strong algorithm, which means that it's harder to break mathematically. It also requires that the key which is used to encrypt and decrypt the data is protected properly.
It's basically like a super password and should be protected accordingly.