This document provides details of iWelcome password management features.
The scope is limited to password management. Management of 2FA-credentials is not within the scope. The authentication process itself (which makes use of password validation) is also out of scope.
iWelcome provides several password management interfaces which are described here. Use these interfaces to manage the registration and activation processes and to change, set, and reset passwords.
Users can set their password through various processes:
- Registration process
When end-users subscribe for an account, they will be asked to choose a password for their new account.
- Activation processes
iWelcome supports various activation processes that allow users to initially set their password. The processes differ in how they are triggered and what profile details the user needs to provide in order to activate his account.
- Change password processes
A password change process is a process in which users replace their current password with a new one and where they still know the current password. A user may choose to do so himself (and use the Self-Service page) or the user may be forced to change a password that is about to expire.
- Reset password processes
A password reset process is one that allows a user to reset a forgotten password.
iWelcome’s user interfaces use the following dialogue whenever a user is choosing a new password.
This dialogue features:
- list of password complexity rules (depending on configuration)
- possibility to view the password that was entered (click on the eye icon)
- re-entry of password to ensure the user knows the password he’s chosen
iWelcome user interface does NOT feature:
- password strength bar
- changing the ‘visual’ for a rule when that’s met
iWelcome supports the possibility for and end user to change his password on the Security tab in Self-Service application.
iWelcome supports the following flow to reset a forgotten password:
Requesting password reset
When you want to reset your password, you click on the password reset link on the login page and get a form where you can enter your email address or username.
After requesting a password reset, you must be authenticated without the forgotten password. iWelcome can be configured to use one of the following mechanisms:
- Password reset link in email.
- Password reset link in email, AND password reset code in SMS. (when 2FA is enforced).
Note: iWelcome does not support multiple password reset processes for one customer or brand. The choice of the password reset process is determined by “static” configuration and does not rely on user data or credentials.
The links that are used for password reset have the following characteristics:
- They can be used only once (like a one-time password)
- They expire after a configurable period.
Execution of password reset. After successful authentication, users can choose a new password by entering it twice. Users are immediately logged in at the end of the password reset process.
iWelcome currently does not support changing a user's password via the Admin UI.
iWelcome provides the SCIM interface, which allows client applications to manage end users and their passwords. The SCIM API can be used to provision iWelcome with identities. The SCIM interface offers the following password management functionality:
- Use the POST method to create a new identity and set the initial password
- Use the PATCH and PUT methods to update an existing identity’s password
- Passwords can be submitted as plaintext in the request body, but can also be submitted in a hashed format. iWelcome supports various hashing algorithms, see section 0 for more details.
- iWelcome applies a password policy (complexity rules) when passwords are set or updated via SCIM.
By default, iWelcome stores passwords in its identity store which would be located ‘in the cloud’ as part of iWelcome’s IDaaS. When users log in using a password, the password would obviously be validated against that store. iWelcome supports hashing of stored passwords with a range of hashing algorithms, such as bcrypt, md5 and SSHA. By default iWelcome uses salted SHA-256.
A password policy is a set of rules designed to enhance computer security by encouraging users to employ strong passwords and use them properly. A password policy is often part of an organization's official regulations and may be taught as part of security awareness training. The password policy may either be advisory or mandated by technical means.
(source: Wikipedia) iWelcome has various features that help organizations enforce certain parts of a password policy, particularly the strength of passwords. Which 'password rules' are applied by iWelcome is configurable and can be adjusted through iWelcome's support processes.
iWelcome supports password policies that are considered commonly-accepted best practices in the market. When commonly-accepted password policies are not considered sufficiently secure, iWelcome advises using two factor authentication (2FA) to enhance security.
Furthermore iWelcome rejects passwords:
- Containing the user’s username
- Are equal to the user’s formattedName
iWelcome applies industry standard password rules that are considered best practices by commonly-used identity stores.
iWelcome can enforce password complexity rules with each of the following rules applied as either a standalone or combined ruleset:
- Minimum length. iWelcome recommends a minimum length of at least 8 characters, which is in line with NIST Digital Identity Guidelines.
- Maximum length
Password character set:
- You can configure iWelcome with “whitelisted” characters. Characters not on this whitelist cannot be part of a password. iWelcome considers it as a best practice not to allow spaces as part of passwords, since consumers can be expected to write/record their passwords in a password-vault or application in which case spaces may cause confusion. iWelcome can support passwords that do contain spaces however.
Optionally the following configurable complexity rules can be applied:
- A password must contain characters from a minimum set of characters
- Per character set, a minimum number of characters can be configured
Supported character sets are:
- special characters
- uppercase characters
- lowercase characters
iWelcome applies the password rules in the following interfaces:
- activation processes
- password reset processes
- password change processes
iWelcome does not apply password rules on passwords that are set through the SCIM interface. This allows SCIM-clients to migrate users with “weak” passwords to iWelcome and lets iWelcome enforce stronger passwords whenever a password is changed through the iWelcome password processes described in this document. When hashed passwords are submitted via SCIM, it would not even be possible for iWelcome to enforce a password policy on such passwords.
iWelcome supports password expiry. Password expiry is the process where an organisation requires and enforces their users to change their password regularly, for example every 3 months or half year. Password expiry is a common practice, particularly for employee accounts and to a lesser extent, also for consumer accounts. iWelcome's support for password expiry has the following characteristics:
- It can be enabled per user segment within a single iWelcome environment.
- The password validity period can be configured; it has 183 days as a sensible default. Consumers may log in to their account only a few times per year, so if the validity period chosen is relatively short, it may mean the consumers can use each of their passwords only a few times.
- When a user logs with a password that almost expires, they are prompted to change their password immediately or they may skip that and immediately get access to their account. The password expiry warning period can be configured and has 14 days as a sensible default. Users can choose not to change their password yet, as many times as they like, until the password has expired.
- When a user tries to log in with an expired password, they get a screen that says their password has expired. On the screen they can initiate the password reset process, just as if the user has forgotten their password.
- When a user logs in with a federated social account, the password they may have within iWelcome is not validated.
- In case of two factor authentication (2FA), the password expiry dialogue is executed immediately after the password was entered and before the user is asked to do the second authentication step.
- The OAuth Resource Owner Password Credentials grant allows applications to capture the user's password and submit it in the request for an access token. If the password has expired an error code is returned. The OAuth protocol does not allow to return a warning when the password is close to expiring.
- The expiry of a password does not impact the usage of refresh tokens to obtain a new access token. A mobile application, for example, can exchange a refresh token to obtain a new access token after the password has expired.
One of the following situations may apply to customers that want to introduce password expiry on a user segment:
- If the tenant is using a version of iWelcome that doesn't have the password expiry feature yet, it can be switched on after an upgrade of the tenant. The iWelcome IDaaS will assume that the last date on which the user's profile was updated, is also the start date for the user's password. Passwords for users that haven't been updated recently will immediately become expired.
- If the tenant is already using a version of iWelcome with the password expiry feature, users will probably have a start date for the password. Such 'start dates' are also tracked when password expiry hasn't been yet enabled.
- In any case if iWelcome doesn't have a start date for a particular password, iWelcome will use the last date when any of the user's profile attributes was updated as start date for the password.
Many security specialists (e.g. NIST ) don't value password expiry as a 'best practice'; they consider that users tend to choose weaker memorised passwords when they know that they will have to change them in the near future. iWelcome does not recommend to use password expiry for consumer accounts.
The password history policy determines the number of unique new passwords that must be associated with a user account before an old password can be reused. Password reuse is an important concern in any organization because many users want to reuse the same password for their account over a long period. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but they can reuse an old password, the effectiveness of a good password policy is greatly reduced.
For every identity, iWelcome keeps a password history against which any new password is checked. For security purposes, passwords are stored in a hash format.
- Checking new passwords against history is disabled.
- Password history can be enabled per user segment within a single iWelcome environment.
- Users cannot reuse the last 10 passwords they've used before. This setting is configurable and defaults to 10. A message will pop up on their screen saying You've used this password before, please choose a different password.
- Users cannot reuse any password that was set during the last year. Password history period has 1 year as a sensible default.
- Maximum password history that iWelcome stores has 100 as a sensible default. After that amount is stored, iWelcome purges automatically the oldest passwords.
When a iWelcome customer decides to change the password policy, this does not trigger a password migration process. Instead, the new password policy is applied whenever a user sets a new password, as described in above sections.