Warning message when setting the passphrase system to hidden in NSL

When the user starts SecureLogin the following message appears;

"SecureLogin has detected you have previously set a Single Sign-On passphrase. However, Single Sign-on security passphrases have been disabled by the administrator. If you disable your passphrase, Single Sign-on administrators may be able to view your Single Sign-on credentials."

If passphrases are enabled, they are set when SecureLogin is launched first time for each user.

The following passphrase security options are available;

• User chooses passphrase question and answer.
• SSO Administrator pre defines a list of questions and user selects answer only.
• Passphrase security system can be completely disabled or hidden (disables user defined passphrases but a random key is still set).

In this particular case, the user had run SecureLogin and set a passphrase Q&A. The administrator had subsequently set the preference "Enable Passphrase Security System" to Hidden (equivalent of Disable passphrase security system set to Yes in v6.x) at the container or group policy level.

With Enable passphrase security system set to Hidden, a random passphrase key is derived on the user’s behalf, instead of the user being involved in selecting the question and/or answer. Since the security question will no longer be asked if someone other than the user resets their network password, an administrator could potentially reset a user’s Directory password, logon as the user, and access their Single Sign-on credentials. For security reasons, user defined passphrases are recommended if password based authentication is permitted.

In this case, since the user already had a passphrase set, they were prompted with the message above. The user could cancel the message but it continued to appear unless the administrator specifically set the preference Enable passphrase security system to Hidden on their user object.

The message is designed to warn users the administrator is lowering the security of their Single Sign-on environment. The message does not appear if the user has NOT set a passphrase when the administrator disables the passphrase system. This also prevents an administrator from lower security without the user knowing.

If the user is prompted with the message above (because they already have a passphrase set) they can click OK to hide their passphrase. They must answer their passphrase question to continue, to prevent someone other than the user hiding/removing their passphrase security.

If your organization has decided not to enforce user defined passphrases (so users are not prompted for a passphrase question or answer) set Enable passphrase security system to No before users run SecureLogin.

Note: If you currently have users with passphrases and wish to disable the passphrase security system, every user will be prompted to enter their passphrase before they can disable it (to prevent someone simply toggling this setting for the user without them agreeing). Depending on your environment, this could mean thousands of users logging on and being prompted for their passphrase, which they may not remember and could be locked out of using Single Sign-on. Contact Professional Services before toggling this preference.

If passphrases are enabled, once a passphrase has been set, a random user specific key is generated and a one-way hash of the passphrase answer is used to encrypt this key. The new key is encrypted with the application key and is used to protect your SecureLogin credentials.

If the user’s network password is changed by someone else (e.g. by the administrator because the user has forgotten it), the next time SecureLogin loads, the passphrase question must be answered (if user defined passphrases have been enabled) before SecureLogin will continue. This prevents an administrator (or anyone other than the user) changing the user’s network password and obtaining access to their Single Sign-on credentials and running applications.

Organizations that have smart card PKI based authentication and key escrow and recovery in place may consider setting Enable Passphrase Security System to No or Hidden. With Enable Passphrase Security System set to No, the primary key for SSO decryption is never changed from the user’s PKI private key.

With it is set to Hidden, NSL will seamlessly change the user’s primary key to the passphrase when the user’s smart card is unavailable, and then back to the PKI credentials once they have been recovered.