Gain insights into effective security techniques including patching, cryptography, and phishing prevention. Explore practices to make systems resistant and vulnerabilities more detectable, enhancing defense against attacks.

docker.tar.gz

network-commands

node

It seems like hardly a week goes by without a high-profile computer breach. Why do these happen? How can you prevent them? This course doesn’t have all the answers, but it does outline practices that make life harder for attackers and that will help tide you over until you get a full-time security team in place.

In this course, you will learn 5 simple, yet effective, techniques for preventing attackers from getting into your system. These techniques are related to: patching, software vulnerabilities, cryptography, windows security, and phishing. Within each chapter you will learn the best practices for preventing vulnerabilities and how to make them more detectable. 

This course is based on the Pragmatic Programmers’ book, Practical Security, and is aimed at developers, admins, team leads, architects, technology generalists, and all others who stand guard against the things that disrupt the network.

Practical Security: Simple Practices for Defending Your Systems

## GPUs
[Moore’s Law](https://en.wikipedia.org/wiki/Moore%27s_law) has altered the landscape in this cat-and-mouse game. The problem with using general-purpose hashing algorithms for password hashing is that general-purpose hashing algorithms are designed to be really fast. And Moore’s Law makes them faster all the time. Salting doesn’t increase the number of possibilities that need to be checked; salting only changes the set of possibilities that need to be checked from one population (all the printable passwords under, say, 10 characters) to another (that same set of passwords, each prefixed with the same prefix or salt.) This is very parallelizable and a great task for the many cores in a graphical processing unit (GPU) on a modern video card. [Checking several billion passwords per second](https://security.stackexchange.com/questions/38134/what-are-realistic-rates-for-brute-force-hashing) is well within reach.

Additionally, a [dedicated password-cracking rig](https://arstechnica.com/information-technology/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/) can achieve 350 billion passwords per second for Microsoft’s LM hashing algorithm. 

Keep in mind that these two benchmarks describe the state of password cracking from 2013 and 2014, respectively. Cracking has only gotten faster since, due to Moore’s Law. So the defense against this is to use Moore’s Law to make defenses stronger over time. This is done with tunable password- hashing algorithms.

Tunable password-hashing algorithms can be thought of as carefully salted passwords that don’t just get hashed once. Instead, the password P is hashed to produce hash H1. Then H1 is hashed to produce H2. This is repeated tens of thousands of times. So a defender can decide how much time they’re willing to spend on password hashing at user login time. Something like a tenth of a second might be appropriate. The defender then works backward to see how many hashing iterations can fit in that amount of time. The login logic is then set up to hash that many times on each login. In approximately eighteen months, when Moore’s Law has kicked in again and made it easier to do that hashing operation, the defender can double the number of hashing iterations and maintain the level of security they had at the outset. The tunable nature of this defense is key. As time goes on, the defender can keep adjusting the number of hashing iterations to provide the desired performance/cost tradeoff.

## Password storage done right
Remember how easy it was to get crypto wrong, even if you knew enough to use AES? It’s nearly as easy to get hashing wrong. And, as is always the case with developing cryptographic software, the ways in which hashing goes wrong tend not to be obvious errors that prevent themselves as bugs. They tend to show up as attacks that make researchers famous. So if you’re looking at hashing passwords, you want to use a trustworthy implementation of one of the following algorithms:
1. [bcrypt](https://en.wikipedia.org/wiki/Bcrypt)
2. [scrypt](https://www.tarsnap.com/scrypt.html)
3. [Argon2](https://password-hashing.net/#argon2)
4. [PBKDF2](https://www.ietf.org/rfc/rfc2898.txt)

All of these are solid choices. All of these use salts correctly to prevent rainbow attacks and they’re all tunably slow, so they’re resistant to brute forcing and can become more so over time by adjusting their work factors. Earlier we covered criteria to evaluate cryptographic software even though we aren’t elite cryptographers ourselves. All four of these hold up. They’re well regarded, they’ve been well studied, and they were written by people with great track records. 

 <font size="6">  &nbsp; &nbsp;  &nbsp; &nbsp;&nbsp;  &nbsp; &nbsp;   &nbsp;  &nbsp;   &nbsp;   &nbsp; &nbsp; &nbsp; &nbsp;       &nbsp;  &nbsp;  &nbsp; &nbsp;&nbsp;   &nbsp; &nbsp; &nbsp;   &nbsp; &nbsp; &nbsp;&nbsp;  **Q U I Z**  &nbsp;   </font> 


# GPUs
[Moore’s Law](https://en.wikipedia.org/wiki/Moore%27s_law) has altered the landscape in this cat-and-mouse game. The problem with using general-purpose hashing algorithms for password hashing is that general-purpose hashing algorithms are designed to be really fast. And Moore’s Law makes them faster all the time. Salting doesn’t increase the number of possibilities that need to be checked; salting only changes the set of possibilities that need to be checked from one population (all the printable passwords under, say, 10 characters) to another (that same set of passwords, each prefixed with the same prefix or salt.) This is very parallelizable and a great task for the many cores in a graphical processing unit (GPU) on a modern video card. [Checking several billion passwords per second](https://security.stackexchange.com/questions/38134/what-are-realistic-rates-for-brute-force-hashing) is well within reach.

Additionally, a [dedicated password-cracking rig](https://arstechnica.com/information-technology/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/) can achieve 350 billion passwords per second for Microsoft’s LM hashing algorithm. 

Keep in mind that these two benchmarks describe the state of password cracking from 2013 and 2014, respectively. Cracking has only gotten faster since, due to Moore’s Law. So the defense against this is to use Moore’s Law to make defenses stronger over time. This is done with tunable password- hashing algorithms.

Tunable password-hashing algorithms can be thought of as carefully salted passwords that don’t just get hashed once. Instead, the password P is hashed to produce hash H1. Then H1 is hashed to produce H2. This is repeated tens of thousands of times. So a defender can decide how much time they’re willing to spend on password hashing at user login time. Something like a tenth of a second might be appropriate. The defender then works backward to see how many hashing iterations can fit in that amount of time. The login logic is then set up to hash that many times on each login. In approximately eighteen months, when Moore’s Law has kicked in again and made it easier to do that hashing operation, the defender can double the number of hashing iterations and maintain the level of security they had at the outset. The tunable nature of this defense is key. As time goes on, the defender can keep adjusting the number of hashing iterations to provide the desired performance/cost tradeoff.

# Password storage done right
Remember how easy it was to get crypto wrong, even if you knew enough to use AES? It’s nearly as easy to get hashing wrong. And, as is always the case with developing cryptographic software, the ways in which hashing goes wrong tend not to be obvious errors that prevent themselves as bugs. They tend to show up as attacks that make researchers famous. So if you’re looking at hashing passwords, you want to use a trustworthy implementation of one of the following algorithms:
1. [bcrypt](https://en.wikipedia.org/wiki/Bcrypt)
2. [scrypt](https://www.tarsnap.com/scrypt.html)
3. [Argon2](https://password-hashing.net/#argon2)
4. [PBKDF2](https://www.ietf.org/rfc/rfc2898.txt)

All of these are solid choices. All of these use salts correctly to prevent rainbow attacks and they’re all tunably slow, so they’re resistant to brute forcing and can become more so over time by adjusting their work factors. Earlier we covered criteria to evaluate cryptographic software even though we aren’t elite cryptographers ourselves. All four of these hold up. They’re well regarded, they’ve been well studied, and they were written by people with great track records. 

 <font size="6">  &nbsp; &nbsp;  &nbsp; &nbsp;&nbsp;  &nbsp; &nbsp;   &nbsp;  &nbsp;   &nbsp;   &nbsp; &nbsp; &nbsp; &nbsp;       &nbsp;  &nbsp;  &nbsp; &nbsp;&nbsp;   &nbsp; &nbsp; &nbsp;   &nbsp; &nbsp; &nbsp;&nbsp;  **Q U I Z**  &nbsp;   </font> 


In this lesson, we will look at standard password storage techniques and why they're important to follow.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

More Techniques for Password Storage

GPUs