Well, hi there. My name is John. This is the 2021 OWASP Top Ten skills learning path for INFOSEC, and we have arrived at security risk number 2, which is cryptographic failures. Cryptographic failures, we will hop right into this thing and figure out what this is all about. As we get into cryptographic failures, I want to start off with just a general understanding of cryptography, and I wanted to give a quick definition here. I got this from kaspersky.com, and I thought it was a pretty good definition of what is cryptography. You can see there, "Cryptography is the study or the practice of secure communications that allow only the sender and the recipient to view the contents. The term cryptography is derived from the Greek word kryptos, which means hidden." So we're hiding stuff. It's interesting, when you think about cryptography, some people may think, "Well, cryptography actually does hide the data," and I guess, in a sense, it hides the data, but in another sense, it does not. If you're an attacker, if you're sniffing the traffic as it were across the wire, then you can still see that data is being transferred, you just can't read it because it's all mumble-jumbled, it's all been encrypted. The whole idea of the cryptography is to take data that you want to keep hidden, that you want to keep secret, and you're not necessarily keeping secret. The fact that data is being transferred, you're keeping secret the actual contents, the actual data itself, in terms of what exactly does it say or what exactly is it. That's one thing to keep in mind there. But that's the idea of encryption or cryptography, is to say, "Hey, we want to take what would have been clear, readable text, and we want to jumble it up, we want to turn it into a form that even if someone were to get a hold of it, they have no idea what it says, unless they have the key to unlock that and turn it back into the readable, usable form that it started in." Anyway, so that's the idea behind cryptography. You can see their applications depend on this to keep data safe and secure and most of the data that is sent and received on the Internet today is encrypted. We will go through a couple little statistics here to show you some of that. Cryptography on the Internet. This is from Google. "Google used private data sources to track HTTPS," so that's the encryption, HTTP encrypted, "state of the top of 100 non-Google sites on the Internet." Then you can see there, "These 100 sites that Google is tracking account for approximately one quarter, or 25 percent, of all of the traffic worldwide." When you look at this little table down here at the bottom, the numbers there are referring to those top 100 sites that Google used to track the data from. Google themselves tried to encrypt absolutely everything, whether it's Google itself; they own YouTube or certainly like Gmail, many of the Google sites that you would use, Google Docs or that kind of thing. They try to encrypt as much of that as possible and frankly, they do. When you think about Google itself, by and large, you can think of it as all of that is encrypted. They use HTTPS encryption for basically all of their sites. It's not totally true, but it's mostly true. But outside of Google, these top 100 sites that account for a quarter of all Internet traffic in the world, 97 out of the 100 default to HTTPS, which means that let's say that one of them, this is an example, of course, let's say it was example.com, then if you typed in example.com and you didn't type in the https://example.com, if you just typed in example.com, it would default it. It would redirect you, as it were, over to the HTTPS-encrypted version of that site. Effectively, what that's saying is 97 out of 100, you really can't get around using HTTPS, but that's what they default to. That's what they work on. Then if you look on the right-hand side, the sites that work on HTTPS, so three of the 100 don't necessarily default, but what the right-hand side is saying, sites that work on HTTPS, all of them will work. Of those three that don't default to it, if you were to forcibly type in https:// and then the URL of that site, then it would still work on HTTPS. Which again, you can think of that, HTTPS equals encryption. That's if you're on our HTTPS site, then you're sending and receiving encrypted traffic between the web server and the client. Suffice it to say these statistics right here show you that a vast majority of the Internet traffic today is encrypted. It's a big deal, cryptography. Here's another a little chart. You can see that January's 22nd, 2022 is when this picture was snapped. This was just straight from Google. You can see their security top priority at Google. They're investing and making sure that sites and services provide modern HTTPS by default. We'll get into some of that too, by the way, when they talk about modern HTTPS, not all HTTPS is created equally. There's different algorithms that you can use. There's some really strong encryption algorithms that are, of course, HTTPS, but you can also be HTTPS and use a really weak encryption algorithm. In that case you're still technically encrypted, it's just not very good. It's easy to break it, it's easy to crack in and actually read the stuff because you're not using very good encryption. But nonetheless, you can see across. Let's see, if you go to the left of this slide, January 1st, 2014 up to January 2022. What are we talking about there? Like eight years. It's gone from all of the site across the Google universe of platforms and sites and all that stuff, everything that Google owns, like I said, Gmail, YouTube, etc. They went from 50 percent back in 2014 up to, as of January of 2022, 95 percent. They are almost at 100 percent across their entire platform of encrypted traffic. Anyway, it's again showing you the prevalence or the importance of encryption and just how widespread it is. When we talk about cryptographic failures, effectively, what we're saying is that you can use cryptography on the Internet and like I've just shown you, most websites do that or many, many websites. Certainly the websites that carry most of the traffic on the Internet today use encryption. But there are some shortfalls to how you implement that cryptography. When cryptography fails, or if you don't implement it the way you're supposed to, then it can lead to all kinds of stuff. You can expose sensitive data, you can run into a lot of problems. This one, by the way, this 2021 OWASP risk, and I talked about this in the overview video, but this is more of a root cause rather than a symptom. The sensitive data exposure was a previous OWASP Top 10 risk. But now in the 2021 version, they said that's really happening, sensitive data is being exposed because of some other root problem that's happening underneath that. The root problem that's happening underneath that is the failure of cryptography, whether it's not implemented correctly or the algorithm itself is just not very strong or whatever it is. This would be more of a root cause type risk here in the 2021 version. That's what we're looking at here, cryptographic failures. These are the factors that we've looked at previously. The CWEs that are mapped to cryptographic failures, there's 29 of them. The max incident rate, which is the applications that are affected by these CWEs, 46.44 is the max and then 4.49 was the average across those 29 CWEs. Then you can see the exploits out of 10, 7.29 is the average exploitability, which is pretty high. I mean, it's gone almost 73 percent in terms of exploitability, how easy is it to exploit these cryptographic failure. That's a decently big number out of 10. Then there the average weighted impact, 6.81. That means that there's 6.81 out of 10 business impact to your organization if one of these vulnerabilities were to be exploited. The max coverage is how many of these applications were tested against the CWEs mapped there. Almost 80 percent was the max of the applications tested and then the average was 34.85. You can see there. Then again, out of a little more than 500,000 applications that were tested, 233,788 occurrences of those applications had some form of cryptographic failure, so just about half had cryptographic failures. Then you can see there's just over 3,000 CVEs mapped back to those 29 CWEs. This is an issue where you look at this. I'll just I'll pick on the total occurrences there for a second, 233,000 out of just over 500,000. We'll call it just under half of these applications are vulnerable to some sort of cryptographic failure and again, if you look at this from the perspective of the attacker, then that's 233,000 different applications that you can take advantage of. You have and then if you look at CVEs, those are vulnerabilities, those are exposures, those are ways to get in right ways to exploit these applications over 3,000 different ways to get in and so, while you do have a lot of applications that are not vulnerable to this security risk. There are so many that are, that from the attacker's perspective they could proverbially look across this landscape and see all kinds of options to get in somewhere. Then to flip that around, if you're the security practitioner, you're saying, hey, I'm trying to keep all the bad guys out then, you need to make sure you lock your stuff down correctly and don't have these failures so anyway, those are the numbers, those are the factors that OWASP looked at in order to categorize and rank this certain security risk where it is on the top 10 for 2021 number 2 so it's a big deal. All right, so let's go over just a couple of cryptography basics. This right here is a very simplified snapshot of what's called the TLS handshake and it depends on exactly what ciphers you use and so there are some nuances here, but this is kind of a representation, if you will, of what happens when you have a user on the left and a web server on the right, and you're wanting to exchange encrypted or protected data so what's going to happen is the user in the form of the browser, whether it's on your phone or on your tablet or on your laptop or desktop or whatever so let's say you're using Google Chrome or Microsoft Edge or Safari on Mac or Firefox or whatever. Then that browser, whenever you type in, I'll just use example.com again, whenever you type in www.example.com and hit Enter. Then again, if the site defaults. We talked about this a little bit ago. If the site defaults to HTTPS, then it's the first thing that's going to happen there. Well, after you send the initial get request and some of that stuff, but in terms of the cryptography portion, the first thing that's going to happen is the client, the browser is going to send what's called a client hello message. In that message, it's going to include several things. It's going to talk about the version of TLS. There's different versions of TLS. The most current one as of today is TLS 1.3 and so the browser is going to send across things like that in the client hello message but one of the critical things and the client hello message is a list of supported ciphers and what that includes is things like, hey what type of key exchange algorithm do you support? What type of symmetric cryptography do you support? What kind of hash algorithm, you know, that type of thing do you support? And all of these things you're going to be listed in what's called a cipher suite and so the client is going to send over to the web server and say, hey I'm running on Google Chrome version 1, 2, 3, 4, whatever the latest is. In that version, then it's going to have a list of supported ciphers. Then on the right-hand side, the webserver wanting to talk in HTTPS. Wanting to do this encrypted thing, the webserver is going to receive that client hello. It's going to look at all those supported ciphers and the web server itself will have previously, the administrator of that web server will have previously configured that webserver to support a certain number of cipher suites. Let's say that, the webserver administrator really wanted to lock things down and they say, hey we only want to support TLS 1.3 for example, we don't want backward-compatible the TLS 1.2 or 1.1 any of that stuff. Then we only want support Diffie-Hellman key exchange with elliptic curve, ephemeral keys, and those types of things. We're only want to support AES, GCM, symmetric cryptography, that kind of stuff, whatever it is, then they can really lock those things down, or conversely, the webserver administrator could say, hey you know what? I want to support, whatever the browser is going to come to me with, I want to support that so I'm going to list a whole bunch of cipher suites that I support. In order to be more supportive as it were to the browsers that are out there. Because what if there's a user out there that's stuck on, whatever, some really old browser version, because there's some business need with this application that only require, that can only talk in really old ciphers and it's just not compatible with any of the new stuff and all that, then you may be forced as an administrator on the webserver side to say, hey, I've got to accept all of these really old ciphers. Because of the business application that we're running on this, will not support anything else for 1,000 different reasons, whatever. Then you have to open things up on your web server in order to allow those browsers to get to you. Because what happens is, if there's not a match there, if the user sends over in that client hello message, the list of supported ciphers and then on the web server side, if the web server has its list of supported ciphers with different key links and just all that stuff. If there's not at least one match, then it stops the whole thing. Then basically, the web server says, "Hey man I don't speak any of those or I don't allow any of those ciphers and so we cannot continue this conversation as it were." It just kills the whole connection right there. It's an important thing to have these ciphers match up. Then another important thing is that the web server on the right-hand side, the web server is the one that gets to decide which cipher suite gets used. Let's say for example, the user sends over 15 different cipher suites with all different variations of key exchange algorithms and symmetric key algorithms or symmetric encryption algorithms and all that stuff. Then there's like 15 different things to choose from and on the web server side, the web server looks down its list and it's like, man, I only match maybe five of those, let's say. This is where the web server administrator comes into, the web server gets to decide, "Hey, I'm going to pick cipher suite number 7 or whatever it is in the list." It's going to pick that based on the preference that the administrator on the Web server side has configured. The web server administrator may say, "Hey I really want to give preference to the strength of the cipher, and I want the strongest one to be selected no matter what." Conversely the web server administrator may say, Hey I want to pick the fastest one I don't necessarily care about strength I care about speed. I want to go real fast. The web server administrator would then effectively categorize them not categorize them but like list them in a preferential order on what they want so that ideally if the Web servers number one cipher suites is presented by the user, then it's like bam, that's the one I'm going to choose and that's the one we're going to go with but if not, then it's just going to work its way down the list. All that to say there's a client hello message from the user, the web server makes the decision, and then the web server again, given that there is a match on the cipher suite, the web server sends back a server hello message and it tells the user, hey, this is the cipher suite that I chose for us to use today, for this session. Then you go through a series of key exchange. I wanted to emphasize this really quick in terms of when people talk about symmetric versus asymmetric encryption, that whole thing. This key exchange portion is the asymmetric portion of the cryptography. Effectively what happens here is the user and the web server have to figure out individually, essentially what the symmetric key is going to be for the encrypted traffic that happens after the key exchange. The purpose of the key exchange really is to figure out what symmetric key are we going to use when we go about the encrypted traffic what many people call bulk encryption, the bulk traffic, what key are we going to use? Because the encrypted traffic at the very bottom there is asymmetric cryptography. Which means the same key encrypts and decrypts. The question becomes all right, well hey we can use symmetric cryptography, which by the way the reason you use symmetric is because it's so fast, it's extremely fast. There's other reasons as well, but that's one of the big reasons is it's so fast. But the good news of symmetric cryptography is it's super fast and you can encrypt it with one key. The bad news is you decrypt it with that exact same key. The problem, of course, is if anyone were to steal that key, then they can decrypt everything, absolutely everything. You have got to keep those keys safe. Well, if we go back up to the key exchange part there, some really smart mathematicians have figured out a way to say what if the user starts to calculate a symmetric key and then the web server starts to calculate a symmetric key. Let's say that they share a bit of information across the wire the information that frankly, an attacker could sniff and could get a hold of. But it's a fascinating thing because even with the sharing of some of those bits of information across the wire back and forth, it's not completely impossible, but it's virtually impossible for an attacker to grab that exchanged information and generate the symmetric key on the attacker's own. But the other fascinating thing is that the user, the browser, and the web server can actually calculate identical symmetric keys independent, well, I won't say independent because they do depend on some of the other ones information that shared. But the user calculates, the browser calculates a symmetric key. Then while that's happening, the web server is also calculating a symmetric key. As it turns out, what the key exchange algorithms that are used today, those two keys end up being exactly the same key. Then they can say, hey, now we both have the same key. Let's start to use the symmetric key or the symmetric encryption and use our identical keys now to encrypt all of that traffic. It's a fascinating thing. One of the things that I mentioned there, if the attacker would get a hold of the key, then he could decrypt everything like look at everything. That's where when you start to look at key sizes and encryption strength, those kinds of things, that's where some of that comes into play because the larger the key size or frankly with some of the elliptic curve stuff, you don't have to have a huge key size. It's still realize some really strong encryption. But effectively, a larger key size is going to mean stronger encryption. Frankly it also means more computational power that you need on the web server side or the user side in order to generate those keys. But nonetheless, that's where you get into some of that where you say, well, how easy would it be really for an attacker to decrypt all of that or to crack the key. The answer is, well, how big is the key? Like how strong is the key? Which basically means how big is the key size? If it's a really big key size, then it's going to be really hard for the attacker to recreate that key on its own. If it's a really small key size, then the attacker may not have that much problem recreating that key on his own and then he's like, I just created it also now I can decrypt everything. When we talk about cryptographic failures, that's one of the things that we look at is what is the strength of the key that is used in the symmetric encryption down there on that bottom part, that encrypted traffic? I know that was a lot right there for that one little slide, but hopefully that sheds a little bit of light on some of the basics of cryptography when it comes to encrypting data between browser and web server which is, again, you go back to the Google stuff and all the charts and all that we looked at the beginning of this, most of the web traffic on the Internet today does exactly this thing every single time you visit a webpage. I dare say even right now as you watch this info of set skills video, you have access to an encrypted traffic. Look up in your URL up in the little address bar of your browser and see if it says HTTPS and it should and that means that you're using encrypted traffic which means that your browser and the web server that hosts this video did exactly this thing. The client hello, the server hello, the key exchange, the encrypted traffic. It's a fascinating thing. This happens all the time. We don't even know it, so anyway. Let's move on to a little bit more. Here's one example when you're talking about cryptographic failures. Let's say that you have, maybe I'll stick over here. We'll get the right really quick the web app. You have a web application that includes a database and that database holds credit card numbers. The application automatically encrypts the credit card numbers in the database whenever they're stored in there. But let's say that also due to a variety of factors from design to whatever, maybe business reasons, whenever credit card numbers are extracted, whenever they're pulled out of that database, then they're automatically decrypted. Then they're sent on to the user, whatever. Well, let's say that the attacker over here on the left sends a SQL injection which by the way we'll get into that in a lot more detail in the next video, which is security risk number 3, which is injection. Stay tuned for more on that. Well, let's say that the attacker sends this SQL injection attack to this web application and causes that back-end database to retrieve a bunch of credit card numbers. Well, if they're automatically decrypted upon retrieval, then the attacker is going to be able to look at those numbers in clear text because the encryption has already been done. That right there like this, this specific example, is not necessarily a problem of the TLS handshake that we looked at on the last slide that talked about for a long time. This one is a problem with the implementation of encryption. You can have really strong encryption there in that database, but because of the implementation, whenever the credit card numbers are retrieved, whenever they're extracted from that database, if they're automatically decrypted, then that's a flaw in the way that you have implemented your cryptography, and then that's where the attacker could gain access to some very sensitive data, in this case, credit card number. Nobody wants that, and if you've ever had your credit card number stolen or hacked or whatever, I've had that. I feel like everybody's had that probably by now. It's just a headache, it's a pain and I don't know, it's just not something you want to do. Certainly, if you have the web application and knew that company that's toasting off this, you do not want to be the one that has to tell your customers, your clients like, Oh hey, by the way, sorry, I totally exposed your credit card number to this attack so that's not a good day. That's one example of how you could see cryptographic failure in the implementation of how this cryptography is set up with this back-end database. Let's look at another one. Example number 2. Let's say you have a web application over there on the right, and let's say there's a bunch of pages in this thing. It's example.com/home, example.com/login, example.com/admin , example.com/funnypictures, or whatever. Well, let's say that some of the pages for that web application, or support HTTPS or enforce TLS, that is, the Transport Layer Security that's what the encryption is all about, TLS. Let's say that some of those pages are encrypted by default, but some of the other ones you can see there, there's open locks on those bottom two in the bottom right corner of the web application pages. Let's say, for example, example.com/home , just the homepage. Let's say that it's just information, there's some text on there and whatever, nothing really critical. So maybe that one is not HTTPS by default. Let's say example.com/funnypictures also has no sensitive data and so it's okay, we don't encrypt that, so no big deal. If you don't enforce TLS, which is encryption for all of the pages, then that opened yourself up to possible exploits that are out there in the wild that an attacker could use to say, Oh, hey, I'm going to trick you into spilling data on pages that are encrypted or let's say in another, I know it says there in the middle TLS downgrade attack, let's say that even one of those other pages that is encrypted, let's say that it uses a weak form of encryption. We mentioned TLS right here. There's different versions of TLS. There's TLS 1.0. Right now I mentioned the latest is 1.3, which includes a lot of really strong ciphers. But let's say you're using TLS 1.0, or even before that the precursor to TLS was called SSL and in fact, that's still used, the term SSL, still used a lot today, the secure sockets layer. However, the actual technology, the actual implementation, SSL, is extremely vulnerable, so you would never want to actually use SSL. But let's say, for example, that due to a variety of business reasons or whatever I mentioned this a minute ago, let's say that your web application, when you're configuring that for the encryption cipher suites, let's say that for whatever business reason you have to support on one of your pages. Let's say you have to support a really old version of TLS or maybe even all the way back to SSL v3, let's just say. Let's say again for business reasons, one of your pages has to support SSL v3 because there's some end-user out there that's on Windows 95 or whatever it is. They just cannot upgrade from that because it's weird business reasons, and so you have to support this really old cryptography. Well, what can happen there is the attacker can take advantage of that. If you remember what I said when a web application when the client sends over the list of cipher suites that they support. Then as long as one of them matches with the web server, then the web server is going to choose and say, okay, this is the one we're going with. Well, what if the attacker were to figure out a way to say, all right, this web application supports SSL v3, which is a really old version of the secure sockets layer. The precursor to TLS. It's really weak encryption. It is encryption, it's just extremely weak. It's very easy to break. Let's say that when the attacker sends over their list of cipher suites that the browser supports. Instead of sending over like what most of us would do just automatically without even knowing it frankly, but say if you're using the latest version of Google Chrome or Firefox or Safari or whatever, then you're going to send over some really strong cipher suites and not even know it. But if you're an attacker, you're going to knowingly and consciously say, okay, I'm going to craft the list of cipher suites that gets sent over to the web server, and I'm going to make sure that the only one I send over is the weakest one that that web server supports. Then by default you're forcing the web server to say, hey, I'm going to have to pick that one that really vulnerable, that really weak cipher suite. Then at that point, you've got a connection with a very vulnerable cipher suite and then you can launch other attacks that maybe downgrade it from HTTPS all the way down to HTTP. Then now you're in the clear text and then now you're starting to steal users cookies and session keys and those kinds of things. You can replay those and impersonate the user and like an authenticated way. We talked about in the very first OWASP Top 10, the broken access control. How do you give access to someone? What you need to authenticate, who they are. They need to be authorized. Well, if you're using this cryptographic brokenness, then an attacker could grab an authenticated users session key and replay that. Then you, in terms of access control, if we go back to the last security risk, then now you're giving access to an attacker and may not even know it. But you're giving that because you, ultimately you had a problem with your cryptographic implementation. That's how some of these things can really start to play together, and create some big problems. But nonetheless, it opens up the door for these attackers to be able to do some bad things. That's a bit about that example. The question is here, are you vulnerable? The first thing, and you can see it there, you need to determine the protection needs of your data. Data in transit, which is moving data, data between web server and browser, or data at rest like in that database example. You can use the encryption either way. You can see their passwords, credit card numbers, personal information is going to require extra protection. That stuff needs to be encrypted. Then certainly there's different privacy laws. There's like a legal implications here. There's legal mandates like the GDPR, the General Data Protection Regulation or other financial stuff like PCI, DSS, those kinds of things. If you have credit card or financial transactions, there's different rules around that. You need to determine what data you have and the protection needs of that data. Then you can start asking a lot of these questions. Is any of the data transmitted in clear text? Frankly, today, here we're 2021, 2022 and beyond, you need to encrypt everything. There's no reason to not encrypt everything. I've mentioned this one a couple of times now that second question, are there any old or weak cryptographic algorithms? Are protocols being used. Either default or just even allowed. You need to be aware of what you may be opening yourself up to. Or their default crypto keys in use, weak crypto keys, that thing. The proper key management, which again, if you have a key that's generated and an attacker gets a hold of that. Then you need to rotate your keys. You need to make sure you don't reuse the same key for multiple sessions. You can force your way into saying, hey, I'm going to use this key for this session. Then as soon as you close down your browser or the session ends, whatever, then you want to revisit that side again. That's fine. But we're going to regenerate a whole new session key. That gets into the what's called ephemeral keys. Ephemeral is just a word that means it doesn't last for very long, it's very short lived. When you see that word, sometimes you'll see in different cipher suites like DHEA, that's Diffie-Hellman Ephemeral or sometimes you'll see EDA. It's Ephemeral Diffie-Hellman, it's the same thing, it's just written two different ways. Anyway, so when you talk about ephemeral keys, it just means that you need to use a new key every single session. The next one there is encryption not enforced or is it enforced? There's things like HTTP headers, there's security directives that can be sent and so if you're not using some of those security directives or certain security headers, then you need to be doing that. Are the received server certificate and the trust chain properly validated? I didn't get into all this. It's a whole another discussion and frankly, but the whole certificate and certificate authority. There's a certificate as part of that client hello and that server hello if you go back to that handshake, we talked about. There's a certificate that is passed from the server over to the user or the browser to say hey, I am who I say I am, the browser's going to say RU, the correct site and sometimes you've probably been seen this along the way. Depending on what browser you use, you may click on a certain link and it may say, hey, there's a problem with this site certificate. Are you sure you want to proceed? The reason for that is you can have an impersonator, an attacker that sets up an impersonated sites that doesn't have a proper certificate to validate that you are visiting the site that you are intending to visit and so if that's the case, then your browser pops up and says, hey, this is certificate is not looking right so this may not even be the right site. Are you sure you want to proceed? So you as the web server administrator, you need to make sure that the certificate that you provide is properly validated and trusted and all of that so make sure you're on top of your certificates. Is randomness used for cryptographic purposes that was not designed to meet cryptographic requirements? This gets back into this a whole another discussion as well but the bottom line is, whenever the browser and the server start to share information like the key exchange, that thing, that is effectively rooted or founded in random number generation. In many cases it's a prime number, certainly with the RSA encryption algorithm but nonetheless it's a random number generator. Well, you can imagine if there is a random number generator that doesn't really randomize numbers very well and you as the attacker, can actually take advantage of the random number generator part of this entire situation, then you can start to guess what the next random number is going to be and if it's not as random as it needs to be, then you as the attacker have the have a step ahead there and you can start to calculate some of these encryption keys so that's a problem. If you as the web server administrator, you're trying to use randomness for cryptographic purposes but the random number generator that you're using was never designed to be a random number generator for cryptographic purposes. That's next level random number generator. This is not just a, hey, pick a number between one and 10 and whatever. There are some random number generators out there that are specifically designed for cryptographic purposes so you need to make sure you're using those random number generators or that randomness that's specifically designed for cryptographic purposes. Then that last one, deprecated hash functions, or frankly, just functions in general that are not strong. You can see there MD5 or SHA1, the secure hash algorithm, version 1, those are just old and they're easily broken right now. There's known exploits out there that are widely used and known and all that stuff that an attacker could. If you use MD5 or SHA1, then you're opening yourself up to basically saying, hey, you can look at all my stuff because these are very easily broken. Anyway, so if you're using things like that, then don't basically use this stronger versions. Those are some things that you can take a look at to say, am I vulnerable to some of these cryptographic failures? And then let me go through these really quick protect yourself, so classify your data so you know what needs to be protected, what's sensitive, what's bound bas, laws and privacies, regulatory requirements, that kind of thing. Don't store sensitive data unnecessarily. Discarded it as soon as you can. You can see there at the end of that second bullet, data that is not retained, cannot be stolen. If you get rid of it to the extent that you possibly can, then no one's going to steal it or at least we're not going to steal it from you. Make sure that you're a good citizen of the sensitive data. Make sure you encrypt all sensitive data at rest. I mentioned this before. Just encrypt everything as much as you possibly can. Whether it's data at rest or data in transit, data in motion, encrypt it. Certainly, if it's at rest, it just means that it's sitting there. It's just sitting on some hard drive or sitting in some database, but it's not moving between web server and browser. Data at rest, make sure any of that sensitive data is being encrypted. Then ensure up-to-date strong algorithms, protocols, keys, use proper key management. We talked about this a second ago. You just want to make sure everything is strong and up to date, the latest and greatest as it were. Then you can see there encrypt all data in transit which secure protocols. I know I've talked about this already. TLS with forward secrecy. Forward secrecy, it's an effect that you achieve most commonly by using the Diffie-Hellman key exchange. Specifically, you'll hear forward secrecy that's you can equate forward secrecy with Diffie-Hellman key exchange algorithm. Then you'll also hear a term, perfect forward secrecy. Perfect forward secrecy uses the Diffie-Hellman, but it uses Diffie-Hellman ephemeral key exchange. We talked about ephemeral a second ago. Frankly, one of the really strong ones these days is Elliptic-Curve Diffie-Hellman ephemeral. You may see that along the way in like a cipher suite. But that's a key exchange algorithm that is very strong. It's very good today. You see there's cipher prioritization by the server, those kinds of things. We talked about that where the server is going to prioritize the stronger ciphers. You enforce encryption using directives. These are some of those security directives like HTTP Strict Transport Security. What that is, the HSTS, that basically forces the browser to use HTTPS encryption. It forces that the communication between browser and web server. It forces that regardless of whether you want to use HTTPS or not. It effectively forces the encryption issue. Then the last one there disable caching for response that contains sensitive data. This is where it's like, "Hey, I'm going to cache this response. It's got sensitive data in it that opens up the possibility that an attacker could come in and disrupt that cache or maybe steal that and then gain access to sensitive data." That's a way you can help secure your data. Here's a few resources and I won't go through every single one of these, but I would just mention that second one there, that's the ASVS. I've mentioned that one in a different video. That's the standard that OWASP puts out that you can actually apply to your application and say, "Hey, are we building this thing or are we securing this thing properly?" That is the actual standard that you can use to grade or look at your specific web application. There's a few cheat sheets in there, from TLS to passwords to, there's that HTTP STS. It's the HSTS cheat sheet. All kinds of good stuff out there from OWASP on cryptography, how to implement this stuff, and how to make sure your applications stay safe and secure and make sure you don't spill any sensitive data or any other problem that would arise out of a cryptographic failure. Cryptography itself, it can be pretty challenging. It's pretty involved. There's a lot of moving pieces to it. But it's an important thing. You've got to implement this correctly. It's a critical part of keeping your applications safe, keeping your customers' data safe, keeping yourself out of the headlines. You're on the next big, "Hey, there's a huge data breach and it's because the application didn't use the proper cryptographic ciphers or whatever it is." Hopefully, you've picked up some stuff here on cryptographic failures and cryptography in general and how big of a deal this is in web applications today. With that, let me say, thanks for hanging in there for this cryptographic failures video. I look forward to seeing you in the next one as we go through the 2021 OWASP Top 10.
