There is a tremendous amount of material on the theory, use, and application of Passwords (among other things). In fact, there are over 2B Google hits for the word, "password", whereas there are, "only" 1.5B for the word, "God". This article is not intended to cover information associated with operational philosophy or effectiveness, but instead focuses on the policy implementation that's available for your use.
To use SSProtect, you Login with a Username and Password combination. Your password is supposed to represent a secret that nobody knows, helping to prove that you are who you say you are. Password Policy is implemented to insure users choose strong passwords that are not easy for attackers to guess or, "brute force". For example, the word, "password" itself is a very common choice, and top choices are documented and used by attackers to break into a variety of services available to unsuspecting users.
Password Policy Details
Password Policy allows privileged users - Administrators and Delegates - to create requirements for Passwords used by Organization Users. Individual Account holders working independently can also manage their own Password Policy.
Though this may seem counterintuitive, it is not because it serves as a reminder to both change your Password on a regular basis, and also allows you to define minimum requirements and forget about them - you will be forced to adhere to them later. Finally, if you later transition to Administer an Organization, policy is already set for new Users you invite.
Password Policies are optional, and can be added, changed, or removed at any time. Policy Requirements include:
- The minimum number of characters in a Password
- The length of time before a Password has to be changed
- The required set of character types that must be included
Setting Password Policy
An Organization's Password Policy is configured from the Administer Users display that can be reached from the notification icon's context menu. Individual Account holders can find the same entrypoint from the Account Configuration display, also accessible from the notificaiton icon's context menu.
On the right side of the either display, you will see a Pwd Policy checkbox, which is checked if a policy is in effect, else unchecked. Choose the Policy Detail button beneath the checkbox to display and modify details:
Use the controls in this dialog to determine whether or not you wish to enforce a Password Policy first by checking (or unchecking) Use Policy. Modify the Min Length, duration (Change After), and the required characters (Lowercase, Uppercase, Number, and Symbol checkboxes) you want to require for Passwords. For example, if you want to make sure a Password includes at least one number and one symbol, check the Number and Symbol checkboxes. Leaving the Lowercase and Uppercase checkboxes unchecked allows for Passwords that do not include any letters at all. Unless you have good reason to avoid doing so, you may want to be sure and choose the Lowercase checkbox to avoid confusion. Note that SSProtect does not require this.
You can only request a Policy that requires a Password of maximum 15 characters in length while also lasting up to 254 days.
Requesting Immediate Changes
In some cases, companies that are managing security incidents will request that all Users change their Password on next Login. You can force this condition by choosing the Force Immediate Reset on Next Login. Existing User sessions will continue to be valid, however the next time a User has to Login, he or she will be forced to update their password before they can continue. Though SSProtect goes to great lengths to insure Passwords remain protected, and due to the unique KODiAC Architecture and granular two-factor authentication requirements, this should never be required. It is available, however, should you wish to enforce the change.
Password Policy applies to all Users, including Privileged Delegates and Administrators. This means changes will apply to your Account and go into effect the next time you Login. If you force immediate changes, you will need to update your Password the next time you Login. This is one way for Individual Account holders to reset their own passwords.
Honeypot Passwords and Password Reset
Password Policy does not apply to Honeypot Passwords, though when you execute a Password Reset request, the Honeypot Password is reset along with your Login password. As noted in related Honeypot documentation, its' password should be set early in the lifecycle of SSProtect usage, or immediately after Reset. See the article Deploying Honeypots for more details.
Password Reset is different than changing your password due to Policy, or by manually executing a change. Both of the latter require your existing password, whereas a Reset request is used when you have forgotten your Login password. The procedure is similar to that used when Organization Users Register an Account, and you will be reminded to set your Honeypot password on the next Login with the new password.
As you change your Password Policy, you may notice the Score changing at the top of the display. This changes when you choose one of the character checkboxes - choose Update to see the new calculation after you change the Min Length.
The Score provides an estimated average duration for an attacker to brute-force (guess with a computer) a single password that adheres to the stipulations shown in the dialog. This value is noted in seconds, minutes, hours, days, years, or millennium depending on the result. It's better to choose a policy that reflects an estimated Score that far exceeds the lifetime of a Password, i.e. the Change After xyz Days value that you choose (up to 254 days). If you choose a combination resulting in a Score that is shorter than your User's Password lifetime, SSProtect will present a warning message when you choose OK. Note, however, that the software will not force you to changes Policy. This is consistent with our philosophy of providing tools and recommendations but allowing you to make the final decision.
Additional details on the calculation, and how you can affect the result, are provided at the end of this article.
When you are finished declaring your Password Policy, select OK. Changes are immediately committed to your Organization's configuration. If you are using two-factor authentication, you will be asked to provide the 2nd-factor then policy changes are saved. If there is a problem, you will receive a message else a simple success message is printed at the bottom of the Administer Users dialog.
How Changes Affect Users
Users are prompted to change their Passwords on login, when applicable. Notices that an Account's Password is about to expire start 5 days before expiration, and are presented after you provide a valid Password during login. Users can change their Password anytime during this 5 day period. When 0 days remain, the Password is expired and SSProtect cannot be used until a new Password is created. Do this by choosing Yes when prompted to make the change.
When a Password Policy is changed, unless specified by the Policy, existing Users don't have to respond on their next Login. Instead, existing Users entertain a Grace Period before Password expiration. This period is equal to one tenth the Policy's new configured duration. Therefore, if you apply a Policy that allows 100 days before a change is required, all existing Users have 10 days to make the change (starting 5 days out when notices are presented during login). If for some reason you choose a duration of less than 10 days, all Users get at least one day. This does NOT apply when the Policy calls for immediate change.
Once a Password Policy cycle has been completed, Users change their Passwords which remain valid for the full duration of the (unchanged) Password Policy. When the Policy is modified, the Grace Period again goes into effect.
Validation with Administrator Changes
Password change due to Policy does not require Administrator Validation, as is the case with on-demand requests for Reset. For example, when a User forgets his/her Password and requests that an Administrator Reset his/her Password, he/she is sent a temporary password via email. The password in the message is used for his/her next login, at which point he/she must supply a new password (that meets the Policy requirements in terms of length and character content). This requires that the Administrator then Validate the Account before it can be used. This is due to the fact that the temporary password is sent in unsecured email, allowing a privileged Administrator or Delegate the ability to check with the User to insure he/she performed the login and set the new Password rather than an attacker who intercepted the email. This is critical due to the ease with which Organization data can be shared.
Note that Administrators and Individual Account holders do not follow a Validation process. Speak to DefiniSec Support if you need a Password Reset or have problems accessing your Account while working through the Reset procedure.
Score Calculation Information
The Score of a Password Policy is based on an attacker using a Brute Force method to find a Password's value. SSProtect protects against Brute Force attacks using a number of different layered methods, and as a result it's more than a little difficult to even setup a scenario where Brute Force attempts can be made with high performance.
But let's assume for a moment an attacker figures out how to create a scenario where he/she can perform such an attack. The Score provides an estimated amount of time a reasonably skilled attacker would need, with the proper specialized equipment and resources, to engage in guessing every possible Password combination that exists. The Score is the amount of time required, on average, to recover a single Password's value that matches the configured Policy.
This average is actually the time it takes to guess 1/2 of all possible combinations available using the minimum required Password. As you require more characters and more character types, the Password complexity increases and thus the total number of possible combinations grows. The greatest impact you can have on the increased complexity is in the number of required characters.
Impact on Score
Requiring a Number has the least impact to an attacker's problem. Requiring that a Password be an extra character longer has the most impact to a given Policy. Doing both is even better, though remaining options, in decreasing order of impact to a pre-existing Password Policy, are requiring a Symbol, then both Lowercase and Uppercase characters (independently), followed by a Number (as noted).
Score Equation Details
The equation that governs this calculation is based on the # of potential password characters raised to the power of the # of required characters, then divided by 2 and again divided by a performance factor.
The performance factor, in this equation, is the ratio of guesses/ second an attacker can compute vs. the amount of, "stretching" the Password algorithm implements. Many good Password algorithms are specifically designed to take a relatively long time to compute a password's derived materials, which are then used by an application. These algorithms provide for a significant amount of stretching, though this then slows down the login process. The performance ratio is the direct result of this stretching as it applies to the number of guesses an attacker can execute every second. For SSProtect in v4.4.2, a reasonable value for today's hardware/ software and attacker capabilities is ten million.
This article was updated w/ v4.7.5 of the :Foundation Client