Proper Password Management

Possibly one of the most poorly understood and overlooked problems faced by businesses and consumers is the proper implementation and management of passwords. Typically, access is granted to a system or resource simply by entering a username and password. Usernames are typically email addresses or some combination of the user’s first and last name, so these are easy to guess. For years, passwords have been in use and created without regard to complexity or uniqueness. More recently, many resources have started to enforce longer and more complex passwords. Unfortunately, people being what they are, often use the same password to access resources from different providers. This practice is known as password reuse.

Unfortunately, many well-known sites have experienced breaches – events where malicious actors (hacker has a different meaning) gained access to sensitive data including password databases. Modern best practices call for passwords to salted and hashed (not a term to use in Waffle House) with the salted hash and the salt being the only data stored. Think of a salt as a randomly generated string that gets appended to your password string before the hashing algorithm is applied. Without going into much detail, hashing a function that takes a variable length string and returns a fixed length unique string. In theory, two identical strings would have the same hash and there would never be a case where two different strings would result in the same hash. A properly coded web service should only be storing the salt and the hash of your salted password.

When you log into a web site or device, the password you enter is processed in this order:

  1. The salt for your account associated with the username is retrieved.
  2. That salt is appended to the password in the same way in which it was when the password was established.
  3. The application creates the salted hash of the string.
  4. The application compares that salted hash to the salted hash stored in the account profile.
  5. If they match, access is granted, or MFA is requested.

With proper application coding, a breach that exposes usernames, stored salted hashes and the salt would be useless to a malicious actor unless they knew the hashing algorithm and process used to create the salted hash. Even then, hashing is not reversible (it’s not encryption), so it would be difficult for the malicious actor to determine your password.

The bad news is there are still many legacy systems out there that have outdated authentication systems that store passwords in plain text (unencrypted, human readable format) making them easy targets for malicious actors.

Getting back to the issue of password reuse – using the same password for access to multiple critical web sites or devices. Files called password dumps are available for sale or download on the dark web. Malicious actors access this data, write automated scripts to run through these lists and attempt to access high value sites like your Microsoft Portal, banking sites, stock trading sites and anything that could allow them to gain access to easy money or to impersonate you!

How can you reduce this risk both at home and at work?

  1. Don’t reuse passwords – everything you access should have a unique and complex password.
  2. Enable multi-factor authentication (also known as MFA or 2FA) on every site that supports it.
  3. Use a password manager.
    OR
  4. Implement passwordless authentication w/ Microsoft Authenticator or security key

You should install a password manager on everyone’s device. Your current policy should require the use of “a password manager” but as you grow and compliance requirements get more rigorous, you should be updating your policy to require the use of “an approved password manager.” This means that the organization will choose an approved password manager and expect all employees to implement that password manager only on their corporate devices. Implementing other non-approved password managers should not be allowed. Work-related passwords should never be stored on non-corporate devices in a personal password manager.

Why do this? First, there is a cost for a seat for every employee with most password managers. Most password managers allow for the viewing of user stats. If only a segment of the user base is logging in and utilizing the password manager, that means that the remaining employees are either using a different password manager or are not following best practices and using no password manager at all. The company could be wasting money on this service or some people could be expensing other password manager that intermingle their personal and corporate accounts unnecessarily increasing our costs and risk.

Second, its best to narrow the scope of software that is supported across the organization. What does this mean? It means for example, we cannot manage and support 6 or 7 different password managers. In the case of password managers, some organizational passwords (like Wi-Fi passwords, etc.) though our password approved manager may be shared using selective vault control. ideally, the password manager should be linked to your corporate SSO making it easy to control access. Supporting multiple different software performing the same function also increases the footprint of software that must be monitored for security concerns as well as managed in your Vendor Risk Management platform. All of this costs time and money.

We also have no control over the inclusion of corporate passwords in other non-approved password managers. This means passwords could be stored outside the organization or within an employee’s personal password vault. Organizations must reduce the risk of this sort of data leakage as well as limit the number of applications that they must track from a risk and vulnerability perspective.

Password managers make it easy to generate unique long, complex passwords, store them safely and recall them quickly and automatically. Everyone should be making full use of our provided password manager and discontinue using other means for storing passwords including text files, Excel spreadsheets and sticky notes.

At Graylog, we have made great strides in reducing the number of passwords that employees need to remember by implementing single sign on (SSO) combined with MFA within all corporate applications that support SSO. We will continue this trend wherever possible. In the coming months, we will also be implementing passwordless sign on capabilities through the Microsoft Authenticator app and the use of security keys (Yubikeys). Continue to simplify processes while reducing the risk of being accessed by malicious actors.

Start by providing users with the tools and training necessary to manage passwords effectively. Then develop a plan to remove reliance on passwords through the implementation of MFA and security keys.

Jim Nitterauer
Jim Nitterauer
Articles: 11

Leave a Reply

Your email address will not be published. Required fields are marked *