Credential Management: Tips for managing IT-specific passwords and secrets

When working on a team responsible for implementing and managing business applications and services, credentials are created and consumed daily. These credentials may be needed for an in-house department or for managed services teams requiring access to multiple environments; they may be traditional domain accounts running business services, logins to vendor support portals, or secrets used to secure public resources like storage access or API authentication. Regardless of their purpose, the proliferation of credentials across an organization represents a significant risk to security, as these are the ‘keys to the kingdom’ for many applications and services.

There’s been a lot of discussion about least-privileged access but not often does that discussion extend to how IT administrators and engineers should behave when they need to work in a privileged manner. Single-sign on, Privileged Identity Management and other IDM solutions may offer a partial solution and should be used if available. Whether due to cost or compatibility with an application, traditional credentials must still be created and managed frequently and being able to perform tasks efficiently is crucial. Unfortunately, as any regular airport visitor can attest, it’s virtually impossible to add security without taking away efficiency.

How then can we allow teams to work quickly, without sacrificing the security needed to protect your business?  Here are a few tips:

1. A Secure Password Management Solution is a “must have” for IT teams

The first and seemingly obvious answer to keeping track of your passwords is to put them all in the same location. Examples of credentials in spreadsheets and emails abound, and this practice must give way to a secure password manager.

But wait, aren’t they all secure? The reality is there are many products available on the market suitable for consumer use only, though these same vendors provide higher-cost, enterprise-grade versions as well. While using the same product for business as your personal passwords may often make sense, there are some features to look out for:

• Locally Encrypted Passwords – Having cloud synchronization for passwords is great, but who can access those passwords? Ensure your password solution offers local encryption/decryption to protect against any access by a hosting company, often referred to as a “vault”.
• Secure Authentication – As access to passwords is generally provided at will once authentication has taken place, add as much security to authentication as possible. Multi-factor is a base requirement, but other layers like Conditional Access can limit when, and from where a password may be accessed.
• Auditing and Alerting – Keeping records of access to passwords in a repository ensures the ability to investigate any anomalous activity from those credentials. For companies with tight security and compliance requirements, access can be ingested by a SIEM for advanced threat analytics.
• One-Time Passwords – Logins to third-party applications, vendor sites, and mobile apps are increasingly requiring multi-factor authentication, also referred to as two-factor, and the rotating 6-digit code entry known as a One-Time Password (OTP).

Password managers supporting these features add several additional layers of security when passwords are shared among teams, and team members inevitably depart, however it only works when everyone is committed to using it. Create passwords in the repository first, save them, and then retrieve the password to use with the creation of the account. Share passwords via link, not the password itself so that access is audited, and passwords never leave the system. Adopting this approach will add a few moments to creating and sharing the passwords, but this a trade-off willingly accepted to keep a consistent and secure environment.

2. Make strong passwords that are simpler for humans

Part of IT work is creating accounts, and with it having to choose passwords. On the positive side, everyone knows by now not to reuse passwords, or easily guessable values like ‘Password123!’ (hopefully). The takeaway many took from that lesson was to use a ‘complex’ password that looks like a jumbled mess of letters, characters, and if we’re unlucky, all the possible symbols. Quite often I’ve seen people just open Notepad and mash away. But when you’re on a console window with no clipboard or trying to quickly solve an issue from your mobile phone at the airport, this results in an extremely inefficient process. Which would you prefer to try to quickly decipher, and confidently enter correctly the first time?

• A character string like x(01j.lx8*xLI`dFF2 .  
• A passphrase like Temple Smile Note Start 9.

Clearly, the passphrase is a better choice and of late, this recommendation is also repeated ad nauseum. Why then is it one that IT teams have had a hard time transitioning to? There’s no good explanation other than it feels different and maybe therefore ‘wrong’. Perhaps because long-standing password generators are still bound to characters and symbols. Whatever the reason, it’s dated, and the benefits of phrases speak for themselves: I can tell you instantly the “l” in the second example is a “lowercase L” based on the context in the word, our fingers already know how to type words as high rates, and our brains are hardwired to remember only 6 or 7 pieces of information at a time.

So, the next time the opportunity arrives to create a secure password, whether for a service account that will rarely change or just a temporary password for a new employee, always use the same process and ensure others do too. While requirements may vary somewhat, here are some recommendations that apply in most cases:

Do

• Use a phrase, i.e., a handful of words, in place of random strings. You can do the math yourself, but trust that there are more combinations of options here than a 12-digit random string.
• Let a password generator do the thinking for you. Many password management tools allow the selection of Words to replace Characters, and many websites can generate phrases. If you are concerned about sites tracking these generated passwords, use it as a starting point and modify them before use.
• Consider different casing for letters; random casing adds further security but be mindful of ambiguous characters when choosing this approach.

Don’t

• Put common characters like “1” and “!” at the end of your strings to meet complexity requirements when using word phrases, as it adds no effective complexity.
• Use words that occur often together, or form an obvious sentence, e.g., “Happy Birthday 2 You!”, or “Person Woman Man Camera TV”
• Use any form of keyboard pattern for complex password generation, if using complex characters.

3. Categorize and tag credentials for better efficiency and security

When talking about storing a credential, even in a modern password manager, the discussion of metadata isn’t one that comes up often. However, enforcing the addition of some lightweight attributes to your credential storage can help to increase security and efficiency. “Hang on”, you may be thinking, “you said previously we can’t have both!”  That is true, but what we can do is be secure where we need to be, and efficient where we do not need to be as secure. This is achieved by classifying credentials based on their purpose, and level of privilege.

I recommend keeping this simple enough to be flexible and accommodate most new needs, while accurately classifying your credentials and how they are used in the environment as they are created. Although organizing passwords into folders can manage this somewhat, it’s a relatively poor solution when most password managers support the flexibility of additional attributes or tags.

My approach to this has been to classify passwords into a few high-level security categories:

• Standard passwords – Shared logins or keys that are used to access non-critical systems and sites, or service accounts with minimal privileges, such as Wi-Fi access points or   Administrators with access to the password management system can access these freely as needed, and all access is logged.
• Secure / Confidential passwords – Shared logins or keys that are used to access sensitive business systems, such as billing or licensing web sites, or have administrative permissions to their resource, such as DNS modifications or database access. Access to these passwords is limited to specific roles based on the service and alerted on via email or Teams notification when retrieved.
• ‘Break-Glass’ passwords – Shared logins or keys that are used only when access through user account authentication and role-based access control is unavailable. A shortened version of “break glass in case of emergency”, these are highly privileged accounts for resolving other permissions issues, and are not for daily operations use. Examples are default Administrator accounts to system, Linux root accounts, etc. Access to these accounts requires justification and approval to use.

Figure 1. Passwords categorized for auditing and alerting

Using a simple categorization allows us to respond with workflows in an appropriate manner and ensure that parties are made aware of credential use with a potential to perform impactful tasks, while still allowing administrators the efficiency to retrieve passwords as needed.

4. How to manage departing employees and ensuring access is fully terminated?

When an employee departs, access to the password management system should be removed upon departure. This would be preferably managed through single sign-on, or an identity management workflow to ensure this happens consistently and immediately. Keeping all credentials in this repository provides this single point of disconnection, and the action to remove access to all credentials is audited, whereas passwords outside the system would require significantly more effort to locate.

Still there is no feasible path to ensuring a departed employee takes zero valid credentials with him/her upon departure. After all, we’ve just talked about making these passwords more memorable, and nothing but company policy would stop an employee from copying them into a document for later use. Some systems like vendor sites and portals could potentially be reset each time an employee with access departs, but the same can’t be said for critical applications using service accounts, which often come with significant privileges to those systems.

There’s no easy answer to make sure all access is revoked upon departure, but there are some proactive steps that can be taken to minimize the risk and overhead when a concern over departed employee access arises.

1. Group Managed Service Accounts – gMSA’s were introduced to help manage the rotation of passwords used by service accounts across multiple systems. Supported by most Microsoft applications (e.g., SQL, IIS, etc.) these accounts do not set a specific password but communicate securely with Active Directory to obtain the updated credential and provide it to the services. gMSA’s allow the use of the same account across multiple hosts, so they can work well for distributed, load-balanced, or scalable systems. Due to a lack of known password, these accounts cannot be used to log in to any system where they have administrative privileges. For more information on the options and compatibility, review the Microsoft gMSA Support Documentation
2. Limit or Audit Interactive Logon –  For applications where gMSA’s are not accepted, ensure service accounts have the Deny Interactive Logon policy applied to them. Most service accounts will not need interactive logon to perform their application tasks but review any relevant documentation before making this change. For the cases where interactive logon permissions are required, limiting the logon capabilities to specific servers and auditing access is the next best solution. With a consistent naming convention for service accounts (e.g., svc.*) alerts can be configured if interactive logons are detected, reporting the IP address and other information about the attempt.
3. Shared One-Time Passwords – The use of OTP’s is one of the easiest ways to protect against leaked passwords. The use has been associated mostly with online applications, but is starting to be seen more in other areas like VPN connections, appliance interfaces, etc. As a general policy, if the option is there to configure multi-factor/two-factor authentication and provide an OTP, it should be configured. Enterprise password management solutions allow the configuration of the OTP alongside the stored password. Legitimate access to the system then provides both credentials to log into the site, where the password alone is rendered useless.
   
   

   Figure 2. Passwords and OTPs can be stored together

4. Periodic Rotation or Expiration- For systems that meet none of the requirements for the capabilities above, it’s still a good plan to rotate passwords and secrets that others may have retained outside the system. Systems that are accessible on the internet are the most critical, and don’t forget about access tokens to resources like storage accounts and key vaults that may be used by APIs. If possible, without major business interruption, set these to automatically expire at the correct time according to company policy. Otherwise, store the expiration in the password repository and configure workflows to notify in advance of expiration, much like we manage SSL certificates already.