Stealth mode for self-registration
17.2.3.4. Stealth mode for user self-registration flows

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.

    • If uniqueness is not required then enumeration is not possible and there is no need for stealth mode protection.

  • ●
    It is recommended to put channel verification as early as possible in the flow to make attacks on subsequent steps more difficult.

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.

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
  • ●
    Username is configured as email address.
  • ●
    Email verification is enabled.
  • ●
    Setting the login name is the first step of the registration process.
  • ●
    Username is generated automatically.
  • ●
    Email verification is enabled.
  • ●
    Email verification is done as early as possible.
Advantages
  • ●
    Very simple setup
  • ●
    Email address may be changed during the lifetime of the account (not during the self-registration process)
Disadvantages
  • ●
    Email address can never be changed (username is a primary key).
  • ●
    Supporters must understand the difference between username and alias.
  • ●
    Special care should be taken not to expose the username.
Other considerations
  • ●
    Both methods will allow additional aliases to be used.

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.