Common settings for auth modules
The Common Settings page displays configuration options that are applied to all of the authentication modules in IDE Services. To access this page, select Auth Modules from the Access Management section of the Administration menu, then click the Common settings link in the toolbar.
General Settings
The following settings are shown on the General tab:
Setting | Description |
|---|---|
Token timeout | Specifies the maximum lifespan for access tokens. By reducing this value, you limit the amount of time a malicious user who has obtained an access token can access the application. The default is one hour. Shortly before an access token expires, IDE Services uses a refresh token to acquire a new refresh token and access token. As long as the user still has a valid session cookie, this process takes place in the background without logging the user out. Reducing this value has an increasing negative impact on performance, as the application has to replace expired tokens with greater frequency. |
Session timeout | Specifies the duration that a session can remain idle before IDE Services terminates it automatically. This sets the lifetime for the session cookie that lets users access the application without having to log in again when the Remember me option is disabled. |
Remember Me duration | Specifies the duration that IDE Services remembers a login session. This sets the lifetime for the session cookie that lets users access the application without having to log in again when the Remember me option is enabled. |
Email verification | Determines whether users must verify their email addresses to log in to IDE Services. To improve the security of your installation, enable this option. Note that email verification is not required for users who have Low-level Administration permissions. This ensures that your administrators always have access to the application. |
Username field placeholder | Sets the placeholder text that is shown for the username field on the login page. Use this setting to tell users which values are accepted as a username. The default placeholder is Username or Email. For example, if you're using a directory service that only accepts logins with an employee ID, you can show Employee ID instead of the default placeholder. |
Throttling Settings
Throttling or rate limitation helps protect IDE Services from brute-force attacks. The options on the Common Settings page let you apply rate limits to login attempts and requests to verify credentials. Rate limits are applied per login. Rate limits help slow down brute-force attacks by blocking new login requests following a series of consecutive login failures, so they keep your passwords safe.
This feature is designed for use with reCAPTCHA. When rate limitation is applied to a login, the user can solve a CAPTCHA-based challenge and try another password. If reCAPTCHA is not configured, affected users must wait until the cooldown period elapses to attempt another login.
When you enable Throttling by login, use the settings on this tab to manage how throttling is applied to logins and requests to verify credentials.
Setting | Description |
|---|---|
Throttling | Enables rate limitation for logins and requests to verify credentials. |
Trusted logins | A list of logins that are not tracked for failed login requests. Enter each login on a new line. When a user exceeds the max failures per login, the login is shown in the Throttled logins list. To disable throttling for the affected user, click the Add to list of trusted logins button. You can use trusted logins to ensure that your administrators can still log in, even when IDE Services is tracking the maximum number of logins. However, users on the list of trusted logins should take extra precaution to secure their accounts with strong passwords, as their logins are not protected against a brute-force attack. |
Audit | Links to a list of audit events related to changes that have been applied to the throttling settings on this page. |
Throttled logins | A list of logins that are currently tracked for rate limiting. Use this list to track which accounts have recorded one or more failed login within the cooldown period. To add accounts to the list of trutsted logins, select one or more accounts in the list, then click the Add to list of trusted logins button. |
CAPTCHA Settings
The settings on the CAPTCHA tab let you set up and use Google reCAPTCHA.
The reCAPTCHA service asks users to solve a CAPTCHA-based challenge to prove that they are not a robot. This challenge is presented in the following situations:
When registration is enabled for the IDE Services authentication module. Users must prove that they are not a robot to register their own account.
When throttling by logins is enabled and the maximum number of failed login attempts is exceeded. The affected user must complete the challenge to try another password.
To enable reCAPTCHA for self-registration and throttled logins:
In the reCAPTCHA Settings section of the Auth Modules > Common Settings page, click the link to access the reCAPTCHA key management console.
The reCAPTCHA Admin Console page opens.
Click the Create icon in the header.
Register your IDE Services domain with the reCAPTCHA service. reCAPTCHA is a part of Google services, so you can use your Google account to log in. Read the tips provided on the page before you register and generate your keys.
Copy the Site key in Google and paste it into the corresponding input field in the Common Settings page.
Copy the Secret key in Google and paste it into the corresponding input field in the Common Settings page.
Click the Save button.
The reCAPTCHA validation input is enabled for users who register their own accounts in IDE Services or whose logins are throttled.
How to Recover from a Brute-force Attack
Few attackers are going to have the patience to guess the conditions that trigger authentication throttling. They're much more likely to give up and move on to an easier target.
However, if an attacker managed to gain access to the application without triggering the rate limitation, you might have a problem. It doesn't necessarily mean that the throttling failed — it means that you let users create weak passwords that were too easy to guess.
If you suspect that a malicious user has gained unauthorized access:
Check your security logs to identify compromised accounts.
Browse the audit events to detect suspicious activity and identify changes that were performed by compromised users.
Update the settings of your IDE Services authentication module to enforce a stronger password policy. For more information, see Set a Password Policy.
Access the user profile for each compromised account and request that they change their passwords. You can force these users to change their passwords the next time they attempt to log in. Alternatively, you can force all users to change the passwords for their IDE Services accounts. For more information, see Require New Passwords for Hub Logins.