Stealth Mode changes the behaviour of the IAM system to support enumeration prevention for channel verifiable data attributes (e.g. email address, mobile phone number) during a stealth protected operation. To achieve this goal during self-registration, the system will continue processing requests as if the self-registration process had not generated conflicts with an existing account so as to not leak information to the attacker.
Stealth Mode can be enabled in the 'User Self-Registration Flow' Advanced Settings for each flow individually.
To take advantage of Stealth Mode, the following requirements must be met:
- ●The attribute to be protected must be the first channel verification target. Meaning the system must be able verify that the registering user is really in possession of this communication channel.
- ●The attribute to be protected must be unique. E.g. if stealth mode is used with email, no two accounts may have the same email configured.
- ●It is recommended to put channel verification as early as possible in the flow to make attacks on subsequent steps more difficult.
If uniqueness is not required then enumeration is not possible and there is no need for stealth mode protection.
Stealth mode in self-registration has some limitations:
- ●Only the first channel verifiable user item is protected. All other user items (including login names) remain vulnerable to enumeration attacks.
A similar feature is also used to protect accounts against enumeration during authentication.
- For more information see:
- ●
- ●For form-based authentication - 17.4.1.12. Stealth mode authentication (zero information leakage and DoS prevention)
Best practice - Stealth mode in the Loginapp REST self-registration API
During registration we want to enable stealth mode to ascertain:
- ●zero information leakage on the first CVT
- ●channel verification on email addresses supplied by the registering entity
The following table compares two methods, how the stealth mode protection can be used during the registration process:
Email as username | Email as alias | |
Configuration |
|
|
Advantages |
|
|
Disadvantages |
|
|
Other considerations |
|
Best practice - Use of nicknames
Many applications require the use of nicknames to protect their users from each other (e.g. multiplayer games, message boards, etc.).
Best practice is to define a nickname attribute as unique but not as an alias for the following reasons:
- ●Nicknames cannot be protected against enumeration attacks, but player nicknames or names on messages boards are visible anyway and do not need to be enumeration protected.
- ●Configuring nicknames as unique will allow the application to be only aware of the nickname and not the login name.
- ●Using a login name (e.g. email) during authentication makes it easier for the user to remember the login name.