Hi,
The Security Console login form responds differently for existing and non-existing usernames For example typing my username into the "User ID" field will then generate a "Authentication Method" drop-down that contains the options "Password" and "Passcode", which are the two types of authentications method I have setup. However, typing something made up into the "User ID" field will then generate a "Authentication Method" drop-down that contains the options "Password", "Passcode" and "On-Demand Authentication". I (and the majority of users) don't have the "On-Demand Authentication" authentication method (but we do use it for some).
By knowing this information it could potentially allow username enumeration, which would be helpful during a brute-force attack against the application, basically allowing someone to know if it's a real account or not. This type of threat is listed at the following site:
CWE - CWE-203: Information Exposure Through Discrepancy (3.1)
Is there any options that can be set to make the Security Console respond in the same way for existing and non-existing usernames?
Thanks,
David
Hi David,
This is certainly something that was considered, but relates to keeping the login interface simple and limiting information disclosure (but perhaps on the way you were thinking). Many customers don't want to disclose what possible types of authentication methods are available (i.e., "Only show users selections that they can perform.") With the current design, the adversary has to make multiple authentication "probes", one per user, to gather types of authentication methods available. For the vast majority of our customers, users have two methods of authenticating: the Domain/LDAP password (for self-service) and their SecurID. If a user doesn't have SecurID, there is no extra selection or "click" required to enter their password or bypass a selection for something they don't have. There were also issues as the console provides a complex set of authentication methods that can be combined into OR and AND configurations. We could try to display all the various OR and AND combinations, or a static (or randomized?) "No Authenticators" response, but either of these would also leak information about the authentication methods available (i.e. SecurID or Domain password (SSC)).
When combined with a sufficiently tight authentication failure lockout strategy, the disclosure of this information poses little additional risk and simplifies the user experience.
-Piers