Best Practices for IT Password Security

Written by Rajat Bhargava on October 3, 2015

Share This Article

Gartner reports that as much as 50% of help desk calls are just password resets. Meanwhile insecure passwords are leading to more high-profile breaches than ever before.

It’s safe to say it: IT has a password problem.

This is something that we’re highly in tune with here at JumpCloud, where security is our bread and butter (we offer a Directory-as-a-Service). Fortunately, there are some amazing tools out there today that can make password management much easier and more secure, including Single Sign-On.

A big part of it comes down to instilling the knowledge of proper practices with your employees. Here’s what they (and you) need to know:

Passwords Facts

  • We’ve reached password overload. The average internet user has 25 online accounts, 6.5 passwords and waits an average of 3.1 months before changing passwords. [Halock]
  • People are getting password-apathetic. 73% of users have the same password for multiple sites. One third always use the same password. [Digicert]
  • Simple passwords aren’t safe. A high-end computer can now crack an eight-character password in 5.5 hours. [Halock]

Common Characteristics of Passwords to Avoid

The five most common passwords in 2014 were:






Women are more likely to choose personal names for their passwords, while men are more likely to pick their hobbies. Time reported on a survey of 2000 people commissioned by Google revealed the most commonly used types of passwords:

  1. Pet’s name
  2. Significant dates (e.g. wedding anniversary)
  3. Date of birth of close relation
  4. Child’s name
  5. Other family member’s name
  6. Place of birth
  7. Favorite holiday
  8. Something related to favorite football team
  9. Current partner’s name
  10. The word ‘password’

Some other common traits of passwords are that capital letters are normally at the beginning and numbers are usually at the end. These types of common characteristics are generally wise to avoid.

Tips to Come Up with a Better Password

Don’t use real words. Gibberish words are much more difficult to crack.

Create Acronym Strings. This is some of the best advice out there for making passwords that are difficult to crack but easy to remember. Just take a sentence or the words to a favorite song and then use every first letter of every word to make a random string. “For those about to rock, we salute you” becomes “ftatrwsy”. If you can add in a phrase with numbers, that could be “too good to be true” (2g2bt).

The Ways that Hackers Hack Passwords

Know the five methods used to hack:

  1. Server Hacking
  2. Hijacking
  3. Trojan
  4. Social Engineering
  5. Brute Force

Best Practices for Passwords for IT Admins

Implement Length and Complexity Requirements

In the world of passwords, the size does count. 8 characters is no longer enough. Most experts recommend at least 12 (we recommend more – 18+ at least).

Complexity also plays a vital role in password security. There are tools that can mandate password requirements of length and complexity automatically, company-wide.

Factors to consider in terms of password complexity:

  • Set length of password
  • Uppercase and lowercase requirements
  • Number requirements
  • Special characters
  • Password reuse
  • Password attempt lockout settings

Create a Password Policy

Every company should have a password policy – ideally one that is audited and updated regularly.

Of course, it’s not just enough to have a policy. You must educate your staff on it (and then educate them again). Here’s some advice from Alan Shimel in the Doing More Faster [free ebook] that really resonates:  always educate on the “why” behind the policy. People are more motivated to adhere to a policy when they understand and respect the reasons that underpin it.

Implement Passwords Across Devices and Applications

Some organizations still have their heads in the sand about the breadth of password requirements. They allow BYOD without creating a policy around it or gaining control of the devices.

Don’t neglect the need for passwords on networks, routers, mobile devices, and for all apps in use. You don’t want the next lost phone to be the next big breach.

Note:  check out our guide to some of the best practices in BYOD.

Do Not Use the Same Password for Multiple Accounts

What happens when a CEO uses the same password for accessing a confidential business network that they use for their social media pages? Just ask the 6.5 million users who were hacked on LinkedIn.

It’s “never going to happen to you”… until it does. Be smart and don’t ever mix business and personal credentials. Automatic password rotation can enforce this company-wide.

Use a Password Manager

In our run-down of the top time-saving tools for IT admins, we featured both KeePass and LastPass as strong options for password management. KeePass is a more stripped-down, lightweight password manager with a 5 Star rating on SourceForge. LastPass includes a very useful Security Challenge, which reveals holes in passwords and how to fix them.

Educate Your Staff on Social Engineering and “Phishing” Attacks.

These hacking methods are cleverly disguised and require the victim to be a willing participant in undoing their security. That’s why it’s so important to teach your workforce about what a “phishing” attack looks like.

The basic rule is this:  whenever you follow a link that asks for login credentials (or any other personal information for that matter) you must be highly vigilant. If you’re not certain if the request for information is legitimate, then you can type the site’s known URL into your browser to make sure you’re not on a carefully disguised imposter.

Automate Password Rotation:

Use a password manager to require the regular changing of password. Required password rotation is essential to staying one step ahead of potential hackers.

Some systems require rotation but then allow a user to just switch back and forth between two passwords. Ultimately, this subverts the goal of password rotation. JumpCloud’s platform catches this issue and allows admins to eliminate previous passwords as an option. This allows IT to set a number of previous passwords back that a user cannot use when rotating.

Employ Multi-factor Authentication

Starting to get the sense that a passphrase alone isn’t enough to secure your network and resources? Multi-factor Authentication (MFA) requires an additional layer of security, like the name of a childhood pet or the use of a token held by the user (e.g. a phone or USB drive).

Navigating Risks in Third-Party Password Policy

By CTO Topher Marie

The other day a coworker and I were discussing some internet sites and their terrible password policies. No white space. Some have no special characters allowed. Some have short limits on how long your password can be. All of these rules reduce the strength that a password can have – American Express used to enforce passwords between 6-8 digits and with only letters and numbers – trivial to crack if they ever were to be breached. They’ve improved since then, but you can easily find sites – even financial institutions – that force you to have weak passwords. So why do they do that?

First off let’s knock down some of the illegitimate reasons we’ve seen offered in the past:

  • Long passwords take up too much space. If they’re storing your password in its original form, then yes, they are morons. All passwords should be hashed, and the hashed values of passwords are always the same length, regardless of how long the original password was.
  • More time typing means more time that you can be observed and hacked. What? If you have one character and they observe that, then you’re done. If you have 5, same. If they watch all 56 keystrokes (assuming I actually typed my passwords) then of course they would have got the 8 strokes it would have taken for their lame password.
  • Long passwords are hard to remember. True – you should be using a password manager.
  • Special characters break the hash algorithm. C’mon now. Either you’re stupid, or you think your users are.
  • Special characters can be used for sql injection. Uh, if you’re not sanitizing your input from web forms then telling users “please no special characters” isn’t going to protect you even in the slightest.

So seriously, why are there these restrictions? I can only think of a couple of reasons.

The first is plain ignorance. They don’t know what they’re doing. They’re taking in password info, have only the most rudimentary understanding of sql injection so they think that special characters must be bad. And that by saying “we don’t allow those characters” they may think that they’re protecting themselves from that attack. They’re storing in plain text so the length does matter.  Or they actually are dumb enough to think that password length is a risk factor in observation. At any rate – these are not the people we should be trusting with our security.

An equally scary reason could be that they intentionally employ poor password security so they can reverse it. An eight digit password is trivial to reconstruct from the hash. It seems to me we’ve been hearing a lot lately of interested parties forcing (or paying) organizations to reveal personal information. So these companies may have an incentive to be able to have and share the actual password. And that’s scary.

Effective Password Storage Policy

The standard practice is to never store plaintext passwords. Generally, you should be storing your passwords in as hashes so that if the data is ever compromised it will be difficult to reverse. There are many discussions on details on how to do this, hashing algorithms to use, etc., so I won’t talk about it here. Here’s a link that discusses best practices in more detail.

All that said, there are still occasions when you do need to violate these principles. It’s still a common need to have the raw password in the Single Sign-On world. Companies like Okta, OneLogin, and Symplified all have to have access to the actual passwords. Not all sites can authenticate without passwords. Some service providers don’t support SAML, OpenID, or any of the other authentication standards. In that case they fall back to logging you in using your username and password.

Still, these companies have the same concerns around password compromise as the rest of us. They spend a lot of time hardening their infrastructure, as do well all. But in the worst case scenario they can’t fall back on hashing, so they have to take different measures to keep password data safe.

First off, they need to keep people, either staff, or the theoretical attacker, from being able to read the passwords. To do this they use encryption. This is different from hashing — hashing is a one-way mechanism that can’t be (easily) reversed. Encryption involves using a key (specifically, a symmetric key) to render the password unreadable. But unlike hashing, encryption is reversible. Using that same key the encrypted data can be reversed and the original password can be retrieved. So they encrypt the passwords, and store the encryption key for later use.

They also need to store the encryption key separate from the encrypted data. One anti-pattern is to encrypt the password, but store the key in a separate field in that same database. This does no good at all if an attacker compromises the database. Then the attacker has both the encrypted data and the key with which to decrypt it. Instead, you need to keep the key remote from the data. The Open Web Application Security Project (OWASP speaks to this practice). If you are storing encrypted data, you need to store your keys in a separate location.

To do this, the best approach is to keep the key at the application level, not at the data level. Let the application have access to the key to decrypt data, no place else. This strategy also means that you will have different keys for your test data and development environments. It also keeps the production keys out of the hands of your developers and staff.

There are several different strategies for managing keys at the application level. The worst of these is to store the keys in code. Hardcoding keys is bad for several reasons. First of all, at some point you will need to change the keys which will force you to rebuild your software completely. You’ll also be exposing your keys to anyone who has access to your source code. Definitely your developers, and anyone that gets access to your repository. Keeping encryption keys hardcoded in your source is just a bad practice.

There are better options for storing encrypting keys discussed in more detail elsewhere. Things like storing the keys in a configuration file on the server running your code. You could also type the key in manually upon server and/or software startup. There are even complete third-party Key Management System (KMS). These all have advantages and disadvantages, and have varying levels of difficulty to manage.

Of course we prefer to keep passwords hashed, and thus irreversible, but sometimes it’s just not possible. In those cases you have an extra duty to secure your users’ data. Hardening your infrastructure is key, as it is with everyone. Encrypting your password data and storing your keys separately from your data is crucial. Holding onto cleartext passwords comes with greater responsibility to keep them safe.

Resources for Passwords for IT

Password Strength Checker:

This password analyzer from Microsoft can give your password a security strength rating.

Password Generator:

There are a variety of random password generators that can help you to create a password that will be hard to crack. This one from Random is simple, whereas offering from Norton and Passwords Generator feature more control.


One of the biggest obstacles in the way of password security is uninformed staffs. Educate your workforce on the importance of passwords and some best practices with these infographics:  facts about passwords, multi-factor authentication, and password security.


This 38-page document from NIST goes into detail on password management, comparing hacking techniques and password managers.

Directory-as-a-Service (DaaS)

This is what we do at JumpCloud. We provide a cloud-based directory that’s free for the first ten users. Through this we, encrypt, store, and hash passwords, functioning as SSO, a password manager, and a directory all in one.

If you have any questions for us about password security or Directory-as-a-Service, start a conversation with us here.

Rajat Bhargava

Rajat Bhargava is co-founder and CEO of JumpCloud, the first Directory-as-a-Service (DaaS). JumpCloud securely connects and manages employees, their devices and IT applications. An MIT graduate with two decades of experience in industries including cloud, security, networking and IT, Rajat is an eight-time entrepreneur with five exits including two IPOs, three trade sales and three companies still private.

Continue Learning with our Newsletter