HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Add a new idea Subscribe
Status No Plans to Implement
Workspace Domino
Categories Security
Created by Guest
Created on Apr 23, 2020

RELATED IDEAS

Http task should Identify the user status active/blocked before proceed for password authentication

Currently http behavior are like this :

In case you blocked (added in deny group) the user in domino server and and HTTP task is configured to obey this setting, (in server document - ports internet ports web- Enforce server access settings: Yes) and if this user try to connect over the web and passed the credential then http task verify the credential first and then look for server access setting available in server security document and provide the error message "HTTP Web Server: You are forbidden to perform this operation"

In case blocked user try to connect over the web and passed the incorrect credential then http task wait till limitation of wrong password attempt texceeded and after that added user in inetlockout.nsf database and provide the error message "authentication failure using internet password: User is locked out"

Expected behavior :

When user access is globally disabled then http server should Identify the user status first whether its active or inactive then verify password and proceed the request further.

In short : http should act on incoming request as follows 1. verify the user status on server 2. verify the credential .

  • Attach files
  • Guest
    Reply
    |     Apr 27, 2020


    Hi Thomas.

    You are advocating the current implementation. However, You missed something and therefore are wrong.

    Current Domino HTTP implementation allows a malicious actor to identify user names and the security configuration settings without knowing the actual username password:

    1. Please open Domino HTTP URL, enter a valid username (for example Thomas Hampel) and invalid password. You will get Domino HTTP answer >>>You provided an invalid username or password." <<< .

    2. Then please repeat the same and you will get >>>You are locked out, or you have provided an invalid username or password.<<<.

    If you enter non existing user name, then you will never get the second message. This means that the result of current Domino HTTP implementation will tell possible malicious actor if the name (or email) is valid and how many incorrect passwords it is possible to enter before the user is locked out.

    Instead, Domino HTTP should always tell the same thing:>>>You provided an invalid username or password. <<<

    The current idea DOMINO-I-1248 is telling that Domino HTTP is misleading Domino administrators by locking out end users that are globally disabled. Globally disabled users cannot be locked out. HTTP lockout function should only work on the users who theoretically can log in and are not globally disabled. The current behavior is not logical and should be fixed. This idea DOMINO-I-1248 is not telling anything about the error message that should be presented to the end-user, this idea is about the message that is being logged to Domino server's console and is intended for Domino administrators.

    I hope the explanation is now clear.

    Best regards

    Ramunas

  • Admin
    Thomas Hampel
    Reply
    |     Apr 26, 2020

    That means a malicious actor can identify user names (+probably email addresses) just by testing all possible names against the user name field without having to enter the password. This will allow extracting all available user names.

    ...not a good idea.

  • Guest
    Reply
    |     Apr 23, 2020

    The user is locked out message from HTTP task is misleading once user is globally disabled. HTTP task should not check user's password and shoud not change inetlockout.nsf for users who are globally disabled.

Copyright © 2023 HCL Technologies Limited