Stop the Confusion: Keep End Users Secure with Strong Passwords

Security has become ever more complex in recent years. With a proliferation of attacks, an easy way into an organization is through an insecure account. Starting with a strong account password makes a big difference. But, like many aspects of security, what makes a password strong has changed over the years.

In this article, learn what the current recommendations are for a strong password and how you can use a password manager to assist in securing your organization’s service account passwords. Finally, ensure strong passwords are in use across your company with a product such as Specops Password Policy.

This post is kindly sponsored by Specops Software.

Best Practices for Passwords in 2022

A top recommendation used by many organizations is the guidelines laid out in the NIST (National Institute of Standards and Technology) document, 800-63B. Recently updated as of March of 2020, the guidelines include new clarifications and recommendations.

Traditionally end-user password recommendations tended to focus on the following:

• The use of complex passwords including a combination of special characters and numbers.
• Frequently rotate passwords, typically every 90 days.
• The password should be long, and the longer the password the better.

The updates to the guidelines, turn some of these previously held tenants on their heads. Notably, NIST no longer recommends that complex passwords be used with a requirement for a specific number of special characters or numbers. In fact, the guidelines state that no complexity requirements be imposed at all!

The reasoning for this is that individuals tend to prioritize simplicity and will therefore reuse a shared password that meets the complexity requirements over a simpler, but potentially unique, password.

This also leads to the update regarding password rotation, where NIST recommends that no password rotation is required, except when a compromise is known. Often individuals will simply increment an existing password that still meets the requirements, instead of sticking with the unique but longer-lasting password.

Finally, NIST recommends that randomly assigned passwords are at least 6 characters while chosen passwords are at least 8. One would think that the length requirement would go up as the standards mature, but in this case, the thought process is a randomly assigned password at 6 characters is sufficiently secure as is a customer-chosen password at 8.

So, with all this, what does that mean for the end-user? When entering a new or updated password, an ideal password policy and password entry screen should be the following.

• Minimum 8-character password with no complexity requirements. <aside> 💡 Should allow for ASCII characters, spaces, and normalized (NFKX or NFKD) Unicode (ISO/ISC 10646). </aside>
• No password hints, as they have been shown to be insecure.
• Implement rate-limiting to avoid brute-forcing.
• Allow pasting, which enhances password managers, and for displaying the password as an end-user is typing.
• Upon entry, check passwords against known insecure or compromised passwords.

With these improvements to process, based on real-world experience, end-users are subject to easier requirements and an improved user experience!

Leveraging Service Account Passwords in Practice

Up to this point, the focus has been on the end-user, and all of the above are solid practices. What does that mean for the other set of challenges, notably service account passwords? Typically less focused on, service accounts may offer even greater access due to their sometimes shared nature and higher privileges than an end-user.

What then, should the password practices be for a service account? They are altogether not too dissimilar from the end-user passwords. Though not spelled out in NIST, service account passwords should be randomly generated and longer than 8 characters. Since these passwords are not needing to be memorized by an individual, there is no reason that they themselves cannot be longer and more complex.

To assist in usage, a password manager should come into play when talking about service accounts, at the organizational level. How might this look in practice?

Here are two examples, driven by the password manager 1Password, for retrieving a service account password at the command line and another via a REST API service. Both techniques are common patterns but focus on different use cases.

Retrieving a Password from a Command Line Utility

Often, IT organizations utilize scripts that perform critical tasks such as backups or data transformations. Within those scripts, there is often a need to retrieve a necessary password. Traditionally, the password would be stored in plaintext within the script, which means that it is subject to being stolen if the script is simply retrieved by a malicious actor.

One way to avoid this is to use a command-line client from a password manager to retrieve the password during the script run. That way, the password is not stored and only retrieved and used temporarily during the script run, making it much harder for an attacker to steal.

Below is an example of a PowerShell script utilizing the command line client from 1Password to retrieve the necessary credentials to connect to Azure AD to retrieve and backup the group members to a CSV file. As one can see, at no time is the plaintext passwords stored within the script, and if the password ever changes the new password is used on the next run.

Import-Module -Name "AzureAD"

$Credentials = op item get 'Azure Credentials' --format=json --vault 'ATA Learning' | ConvertFrom-JSON

$Username = $Credentials.fields[0].value
$Password = ConvertTo-SecureString $Credentials.fields[1].value -AsPlainText -Force

[PSCredential]$AzureAdCred = New-Object System.Management.Automation.PSCredential ($UserName, $Password)

Connect-AzureAD -Credential $AzureAdCred

$GroupObjectID = '3c97a54d-ec15-4ace-83fb-38cd16761c4f'

$Members = Get-AzureADGroupMember -ObjectId $GroupObjectID
$Members | Select-Object DisplayName, AccountEnabled | Format-Table -AutoSize
$Members | Export-Csv -Path 'C:\\WorkingFolder\\Users.csv' -Force

Retrieving Passwords via a REST API

Of course, retrieving a password through a command-line application is not the only way. Other applications require the use of a REST API. This method may be more suited for applications or scripts that should not depend on an additional executable.

Similar to the previous script, this version is adapted to use the REST API of the 1Password Connect server to retrieve the same credentials, but without the dependency of an additional executable.

The reason for the localhost URI is that 1Password Connect runs as a Docker container. When run locally, this is the default URI.

Import-Module -Name "AzureAD"

$Credentials = Invoke-RestMethod -URI ("http://localhost:8080/v1/vaults/{0}/items/{1}" -F 'hhbmehr5aemywegzr3onmijbpm','ejobbzg5pubyonrerogirykota')  -Headers @{
  'Accept'        = 'application/json'
  'Authorization' = "Bearer $Token"
}

$Username = $Credentials.fields[0].value
$Password = ConvertTo-SecureString $Credentials.fields[1].value -AsPlainText -Force

[PSCredential]$AzureAdCred = New-Object System.Management.Automation.PSCredential ($UserName, $Password)

Connect-AzureAD -Credential $AzureAdCred | Out-Null

$GroupObjectID = '3c97a54d-ec15-4ace-83fb-38cd16761c4f'

$Members = Get-AzureADGroupMember -ObjectId $GroupObjectID
$Members | Select-Object DisplayName, AccountEnabled | Format-Table -AutoSize
$Members | Export-Csv -Path 'C:\\WorkingFolder\\Users.csv' -Force

The $Token variable was previously assigned, but omitted from the script for demonstration and security purposes.

Put Password Management Best Practices in Front of the End-User with Specops Password Policy

Now, all of these best practices outlined by NIST and the industry are for naught if a strong password policy is not enforced throughout. The built-in Microsoft password policies and customization ability are not as comprehensive as many security-focused organizations need.

To enhance and truly take password policies to the next level, a product such as Specops Password Policy is critical to securing accounts.

• Utilize the Breached Password Protection add-on to block compromised passwords in real-time and utilize regular in-depth account scanning to find additional compromised passwords.
• Comprehensive and customizable password policies to meet the unique requirements of each unit, whether an end-user or a service account is in use.
• Granular targeting of policies to make sure the right policy is applied every time.
• Real-time feedback with the Specops Authentication Client, to make sure an end-user creates a secure password at creation.

With all of the threats that exist in the ever-evolving security landscape, using secure passwords, especially in the context of the updated NIST standards is crucial to maintaining organizational security. Products such as Specops Password Policy help secure your organization and your accounts from malicious actors.

Password Management in 2022

Despite the updated NIST standards turning pre-existing notions of password security on their head, the guidelines make a lot of sense when looked at in the context of human behavior and real-world experience.

Utilizing products such as Specops Password Policy to enforce a variety of password scenarios from end-users to service accounts, will make sure that your organization is as secure as it can be from the many external and internal threats that exist. Take your security to the next level by applying the latest in password policies for all types of accounts and ensure they are enforced across the board!