The stealth mode reduces or eliminates risks by doing the following:
- Do not tell the attacker whether the first factor (the password) was wrong: always ask for the second factor even if the password was wrong.
- If the password was wrong, the second factor will always be simulated and it will always fail, even if the correct response is entered. "Simulation" means that the challenge for the second factor is created as realistically as possible (but e.g., no SMS is sent to the user), while all answers are rejected.
- Do not behave differently for existing and unknown users: simulate an authentication process even for non-existing users.
- Never tell the user that the account is locked, even if both authentication steps succeed (e.g. username, password and token correct). This prevents brute-force attacks on passwords if a second factor is known.
If an attacker can determine that a second factor is simulated (e.g. by having access to the victim's mobile phone when using mTAN), they can find out whether a tried password is correct or not. Therefore, wrong passwords are still counted as failed login attempts and will lead to a user being locked after too many attempts.
Using or not using stealth mode is a tradeoff between security and usability:
- Stealth mode ON: higher security but poorer user experience. The (legitimate) user is not told which authentication step was wrong. This may lead to more helpdesk support.
- Stealth mode OFF: lower security but better user experience. The (legitimate) user gets more information if authentication fails. Helpdesk support is generally lower.