Securing Internet passwords

Internet passwords can be subject to attacks by malicious sources. However, there are measures you can take to make Internet passwords more secure.

About this task

Here are some examples of typical password attacks:

  • One type of attack is an attempt to read all the hashed passwords in the Domino® Directory. A user's Internet password is stored in a hashed version in the user's Person record in the Domino Directory. The directory is publicly accessible to all users of the system. You can protect against this sort of attack by using xACLs to stop access to the hashed passwords.
  • Another type of attack is that based on guessing passwords when authenticating. In this type of attack, users can still try to authenticate as someone else and try and guess passwords. You protect against this type of attack by using more secure password format, using passwords that are more difficult to guess, or by enabling the Internet password lockout feature on the server.

Use one or more of the following features to secure access to Internet passwords stored in the Domino Directory, or make them more difficult to guess.

  • xACLs
  • More secure password format
  • Internet password lockout

With the exception of the log settings, the options described previously can also be specified in a user policy. This might be useful if an administrator only wants to enforce Internet password lockout for a subset of users in an organization. In this case, these settings can be established for that group.

Using xACLs to secure Internet passwords

One way to secure Internet passwords is to use Extended ACLs, or xACLs, to control access based on levels in the naming hierarchy, and at the form and field level. For passwords stored in the Domino Directory, administrators can set up xACLs to limit access to Internet passwords to the users themselves, for accessing their own passwords, and to administrators, for allowing administrative changes to passwords.

Procedure

  1. First, enable extended access for the Domino Directory:
    1. Open the database, and choose File > Application > Access Control.
    2. Make sure you have Manager access in the database ACL.
    3. Click Advanced, and then select Enable Extended Access.
    4. Click Yes to continue when prompted: Enabling extended access control enforces additional security checking. See Domino Administrator Help for more details. Do you want to continue?
    5. If the advanced database ACL option Enforce a consistent Access Control List across all replicas is not yet enabled, you are prompted Consistent access control must be enabled first. Do you want to enable it now? Click Yes.
    6. Click OK at the prompt If more than one administrator manages extended access control for this database, enable document locking on the database to avoid conflicts.
    7. Click OK in the Access Control List dialog box.
    8. When the message Enabling extended access control restrictions. This may take a while. displays, click OK.
  2. Next, set up the extended access to secure Internet passwords:
    1. Open the database, and choose File > Application > Access Control.
    2. Click Extended Access. The Extended Access dialog box appears.
    3. In the Target pane, select the root [ /] and click Add.
    4. In the Access List pane, select Default.
    5. Click Form and Field Access. The Form and Field dialog box appears.
    6. In the Forms list box, select Person. Leave the Access settings for Forms blank.
    7. In the Fields list box:
    8. Click Ok.
    9. Repeat this process for the HttpPassword and dspHttpPassword (if it appears) settings in the Person form:
      Table 1. Access List entries in the Person form
      Access List entry Read Access setting Write Access setting
      Self Allow Allow
      [Local administrators group] Allow Allow
      [Local servers group] Allow Allow
    Note: If Anonymous access was previously defined in the access list, it should be set up to deny read and write access to HTTPPassword and dspHTTPPassword (if it appears) fields in the Person form.
    Note: Once xACLs are enabled for a Domino Directory, LDAP anonymous access is not controlled by the list of fields in the All Server Configuration document. Since the default xACL setting for Anonymous is "No Access," once xACLs are enabled all anonymous LDAP searches will fail.

Using more secure password format

When you enter an Internet password and save the Person document, Domino automatically one-way hashes the Internet password field. To improve the default password, use the more secure password format. You can upgrade the password format for Person documents that already exist or automatically use the more secure password format for all Person documents that you create.

For existing Person documents

Procedure

  1. From the Domino Administrator, click People & Groups, and select the Person documents that you want to upgrade to a more secure password format.
  2. Choose Actions > Upgrade to More Secure Internet Password Format.
  3. If all servers in the Domino domain run release 8.0.1 or greater, select Yes - Password verification compatible with Notes/Domino release 8.0.1 or greater. Otherwise select Yes - Password verification compatible withNotes/Domino release 4.6 or greater.

For new Person documents

Procedure

  1. From the Domino Administrator, click Configuration, and select All Server Documents.
  2. Choose Actions > Edit Directory Profile.
  3. If all servers in the Domino domain run release 8.0.1 or greater, select Yes - Password verification compatible with release Notes/Domino release 8.0.1 or greater. Otherwise select Yes - Password verification compatible with Notes/Domino release 4.6 or greater.
  4. Save and close the document.
    Note: The more secure password format is required if you choose to synchronize a user's Internet password with their Notes® password.
    Tip: Another way of preventing malicious sources from guessing passwords is to simply make them harder to guess -- by making the passwords longer and more complex, using a variety of characters, avoiding the use of real words, and so on.

Using Internet password lockout

About this task

Internet password lockout lets administrators set a threshold value for Internet password authentication failures for Domino Web and Domino Web Access users. This helps to prevent brute force and dictionary attacks on user Internet accounts by locking out any user who fails to log in within a preset number of attempts. Information about authentication failures and lockouts are maintained in the Internet Lockout application, where the administrator can respectively clear failures and unlock user accounts.

It should be noted that this feature is subject to Denial of Service (DoS) attacks. A DoS attack is one in which malicious users explicitly prevent legitimate users of a service from using that service. In the case of Internet password lockout, legitimate Internet users could be prevented from logging in to a Domino server by attackers who intentionally make failed log in attempts.

Note: Internet password lockout has no affect on Domino Off-Line Services (DOLS).

There are some usage restrictions for Internet password lockout:

  • You can only use Internet password lockout with Web access. Other Internet protocols and services, such as LDAP, POP, IMAP, DIIOP, IBM® Lotus® Quickr®, and IBM Sametime® are not currently supported. However, Internet password lockout can be used for Web access if the password that is used for authentication is stored on an LDAP server
  • You may not be able to leverage the functionality of the Internet lockout feature if custom DSAPI filters are in use, as the DSAPI filter is a way to bypass Notes/Domino authentication.

For single sign-on, the Domino server on which the Internet password lockout feature is enabled must also be the server that issues the single sign-on key. If this key is retrieved from another source (another Domino server or WebSphere® server), the SSO token will always be valid on the Domino server, regardless if Internet password locking is enabled.

The Internet Lockout database

About this task

The Internet Lockout database (inetlockout.nsf) is created from the template inetlockout.ntf in one of two situations:

  • During startup if the Internet Lockout feature is enabled.
  • The first time the lockout database needs to be looked at or written to. This does not require a restart, but a period of ten minutes must have elapsed between the time the feature is enabled and the time the lockout database is opened or written to.

By default, the Internet Lockout database ACL allows manager access only to the Admin Group. Default and anonymous are denied access. However, the database ACL can be modified to provide users and groups access to view and unlock users.

For each user attempting to log in to Domino using an Internet name and password, information about the lockout state is maintained in the Internet Lockout database, including the user name, number of failed attempts, and lockout status. Lockout attempts are not recorded in the lockout database if the user is already locked out, or if the user logs in successfully. However, while the Internet Lockout database maintains lockout state information, the Domino Domain Manager (DDM) is the location in which login failures and lockout history information should be maintained, providing you with historical records of login failure attempts.

Any changes to the access information for users stored in the Internet Lockout database are implemented immediately. You do not need to restart the HTTP server in order for changes to take effect.

There are two views in the Lockout database:

  • Locked Out Users, which contains records for users who have surpassed the threshold value for failed password attempts and now cannot login to the server with their Internet name and password.
  • Login Failures, which contains records for users showing the number of failed authentication attempts.

The fields are the same for both views:

  • Server name - the server for which the user is either locked out or has failed authentication attempts
  • User name - name of user who is locked out or who has logged failed authentication attempts
  • Locked out - in the Login Failures view, this value can be either yes or no. In the Locked Out Users view, this will be set to Yes.
  • Failed attempts - shows the current number of failed authentication attempts for each user. In the Locked Out Users view, this should equal the threshold setting.
  • First failure time - shows the date and time of the first authentication failure
  • Last failure time - shows the date and time of the last authentication failure. This can also be the time the user got locked out. If the user is locked out and tries again, this time is not updated.

You delete a record to unlock a user.

You can mark multiple records for unlocking or deletion by clicking Mark for Delete/Unlock in the tool bar, and then delete them by clicking Delete Marked Items.

It is recommended that you periodically verify that the Internet Lockout database contains only records of valid users. Remove the names of those users who have had name changes, or who have been removed as users of the Domino server. There is no automatic cleanup of the database; while having outdated user records will not cause functional problems, too many records in the database could cause Internet authentication performance to slow down.

You can create custom login-forms for the Internet Lockout database that can be used to tell users that they may be locked out.

Replicating the Internet Lockout database

About this task

As an administrator, you need to decide whether replicating the Internet Lockout database to other servers is useful for you. A major advantage of replicating the database is that lockout information is replicated to multiple servers. You can look at any replica and determine the lockout status of users across multiple servers, instead of having to open up the Internet Lockout database on each server for which Internet password locking is enabled.

However, replication also has its disadvantages; for example, replication storms can occur if your network is under attack, or if a denial-of-service attack occurs. Additionally, if replication is slow to occur, anyone checking the lockout database on a given server might not be able to see that a person is locked until replication occurs (however, they can always open the replica directly on the server in question).

The Internet Lockout database is created with a replica ID that stays the same for any replica on any server for which Internet password locking is enabled in a domain. By default, replication is temporarily disabled for Internet lockout databases. This is to prevent replication storms described earlier. To replicate the database to another server, disable the Temporarily disable replication option in the Other section of the Replication Settings dialog box. You can then set up the database to replicate (either scheduled or clustered replication).

Note: When you replicate this database to other servers, the 'invalid attempts' information is calculated for each individual server. For example, if the threshold for 'John Doe' is three, and he has two invalid attempts on Server A and has one on Server B, he is not locked out of either server. The attempts are not combined for a total of three. The reason for replication is ease of administration, not to establish global thresholds.

Configuring Internet password lockout

About this task

You enable Internet password lockout in the server configuration settings document. This allows administrators to turn on the Internet Lockout feature across multiple servers.

It is recommended that the Server document option Fewer name variations with higher security is enabled. This minimizes the problem of ambiguous names. Domino supports logging in to the Web server with a short form of the user name (if the password is correct), even though the short name may match two or more people in the directory. Incorrect logins that occur when a user types in an ambiguous name will result in a failure for each ambiguous match, because there is no way to tell which user was trying to log in. Furthermore, failure attempts being cleared using the lockout expiration settings occur only for the user whose username and password successfully match.

Procedure

  1. In the Domino Administrator, click Configuration > Server > Configurations. Open the configuration settings document for the server for which you want to enable Internet password lockout.
  2. Click Security. You have three options for the setting Enforce Internet Password Lockout:
    • Yes - the server enforces Internet password lockout. This option must be enabled for any Internet password lockout functionality to work.
    • No - the server does not enforce Internet password lockout.
    • (Blank) - If this setting remains blank, than the Enforce option is not necessarily disabled, but instead allows another server Configuration doc (perhaps one that applies to all servers) to determine whether Internet password locking is enabled for this server.
      Note: If Internet password lockout is not enforced in the Server document, any other Internet lockout settings, such as those in a policy document, are disabled.
  3. When Internet Password is enabled, complete the following:
    Table 2. Internet password lockout settings
    Setting Specify
    Log Settings You can choose the type of events that you want to log on the console and in DDM. User name and IP address are also logged.
    • If Lockouts is enabled, both the events in which a user has been locked out and events in which a user tries to authenticate but is already locked out are logged. This is enabled by default.
    • If Failures is enabled, any failed authentication attempt is logged. The IP address and user name of the client trying to authenticate are also included in the log.
    Default Maximum Tries Allowed Specify the maximum number of bad password attempts allowed before the user is locked out. The default is 5. Once the user is locked, the user must be unlocked before any new values for this setting are in effect for that user.

    If a user has a different value for the setting in their user policy, it overrides the one set in the server configuration document.

    Note: If this value is 0, unlimited password attempts are allowed.
    Default Lockout Expiration Specify the period of time for which a lockout is enforced. After the specified time period expires, the user account is automatically unlocked when the user next tries to authenticate. In addition, all failure attempts are cleared.
    Note: If this value is 0, the lockout will not expire automatically. The account must be unlocked manually.
    Default Maximum Tries Interval Specify the length of time failed password attempts are retained in the lockout database before they can be cleared by a successful authentication. The default value is 24 hours.

    This does not apply to users who are locked out. If a user is locked out, the only thing that can clear failure attempts and unlock the account is to do so manually, in the Internet Lockout database, or when Lockout Expiration occurs.

    Note: If this value is 0, every successful login, for a given user who is not locked out, clears all failed password attempts by that user.
    Note: With the exception of the log settings, the options described previously can also be specified in a user policy. This might be useful if an administrator only wants to enforce Internet password lockout for a subset of users in an organization. In this case, these settings can be established for that group.