1. Home
  2. Training Library
  3. Amazon Web Services
  4. Amazon Web Services Courses
  5. Introduction to Security Best Practices for Linux Instances on AWS

Best practices to choose your passwords

Best practices to choose your passwords

Launching your EC2 instance is just the first step to becoming an AWS professional: securing your cloud resources is something you just can't ignore. In this course the experienced Linux System Administrator David Clinton will share some common best practices to enhance your infrastructure security.

You'll learn how to manage access to your instances with IAM and Multi Factor Authentication, how to encrypt your storage, how to keep your Linux instance updated with security patches, how to monitor your system and your network to ensure that nobody unauthorized is using your resources, and finally, the basic principles of penetration testing and how to use nmap to ensure that your security group is properly configured.

Who should take this course

This course is aimed even at beginners with little or no experience with cloud security. Some basic knowledge about Linux system administration, TCP/IP, and security topics are recommended.

To increase your knowledge, you may want to check our many AWS courses, in particular the ones introducing EC2 and S3. And why not take the challenge and try out a quiz?


Hi and welcome to cloudacademy.com's video series on security on the Cloud, and particularly, Cloud instances on Amazon's AWS Service. In this video, we're going to talk about password policy. Your whole web services system is only as secure as its weakest password. If you have 10 or 15 or 50 employees participating and contributing to the data and services of your instance, your Amazon instance, if one of those users has forgotten to update a password or has a password that's easy to guess like "password" or their child's birthdate or really any word or even combination of words that show up in a common dictionary, then the whole system becomes vulnerable. This is especially true if this user has access to system authentication through, let's say, sudo.

How can you, as a system administrator, control and ensure that the passwords used by all of your employees are up to standard, are complex enough and are changed open enough that they're actually useful, they're actually going to secure the system. We're going to explore two approaches. One is the traditional Linux approach that is from the command line.

We're going to use a standard Linux command line. It turns out this one is even on the Amazon cloud because the system works exactly the same way no matter which command line you're working from. There are configuration files and there are command line programs that control many details of password policy.

Let's take a look for example using sudo nano. Nano course is the text editing program, and sudo instructs the system to give root user authority. When editing this file, we're going to use that to edit the file called login.defs. It probably stands for defaults; login defaults. It's a long file. We're going to search through the file. Control W will allow us to search for aging, the word aging. This brings us about halfway down the file to a section of the file that controls password aging controls. The way we set these parameters will determine how often the system will require all of its users to update the passwords. Even the strongest password in only useful so long as nobody else knows it. The longer your password has been in use, the greater the chance that someone else has, either through keyboard tracking, software, or just peering over the shoulder of a user, gained knowledge of this password. So the first parameter is password maximum days. That is the maximum number of days the system will allow an old password to continue to remain in use. By default, that's 99,000, which is a long time. Effectively, that means by default, the user never has to change his password, He might change this though to 30. That would mean every 30 days, the user has to change his or her password. Password minimum days mean we don't allow the user to change the password in less than 5 or 10 or 15 days.

He has to keep the same password at least that long. Password warning age means that the system will send an email warning to the user seven days. In this case, it's set in default seven days before the password will expire. So 23 days after this password was created, the system will send an email saying that you have seven days to change or to update your password.

Let's exit this file and discuss password complexity. To do that, we will change directory within the etc. Directory hierarchy change to pam.d and sudo nano common password. Edit the common password configuration file. This one is quite a bit shorter. We'll scroll down to the first line of the primary block. This line begins with the word "password", so it's telling us this line will determine the rules associated with a particular aspect of a user password. These parameters, we like. However, we'd like to add the rule that this password, any password chosen by any user on the system must have a minimum length of, let's say 12 characters. So we type in minlength. Minimum length equals 12. The minimum length of any allowable password that we will permit a user to choose has to be 12 characters. Obviously, the task of the 12 character is going to be a great deal more difficult to guess or to crack than a password of a six characters. Again, to save this, we would click on "Control X" and type y for yes.

But in this case, we don't want to save it. We'll leave it as "No. " However, this is not the only way to control and manage password complexity for your users. Amazon has a web-based interactive tool that does this what we describe. And in fact, more.

So going into the IAM control panel, look towards the middle, a little bit to the left to password policy. At this point, it's disabled. Let's manage password policy. So we can set the minimum password length, we can change it from 6 to 12 as we did in the terminal session we just closed. But here, we can also create new layers of complexity, which will make passwords even more difficult to guess or to hack. For instance, we can acquire at least one uppercase letter. A very good idea. We can require at least one number.

We can require at least one non-alpha numeric character. For instance, the x sign or the dollar sign, In managing the difference when you're trying to hack a password if you know you have only to choose between the 26 letters of the English alphabet. That's going to take a certain amount of computing power through go through all the permutations and combinations. But if you have to choose between passwords, at least 12 characters in length, that not only could contain the 26 characters of the alphabet, but the 26 uppercase characters and all the numbers and all the non-alphanumeric characters, it becomes much, much more difficult. So to up the complexity that will be required of every password create by every user on your system, simply check the boxes that you think should be necessary and click on "apply password policy. That will make a difference in the security of your whole systems and your users will be forced to comply.

About the Author
Learning Paths

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.

Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.

His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.