More Security in OpenOTP Token
Mehr Sicherheit in OpenOTP Token
Attackers have developed new ways to abuse push-based authentication. Techniques such as push bombing (flooding the user with login requests), fatigue attacks (hoping the user approves one request out of annoyance), and accidental approvals (a mistaken tap on the screen) are becoming common. These attacks exploit human error rather than breaking encryption.
If authentication is reduced to a simple “approve” button, attackers can take advantage of that weakness. To counter these threats, authentication must stay simple for legitimate users but also enforce deliberate, context-aware decisions.
The latest release of OpenOTP-Token introduces several new mechanisms designed to strengthen push-based authentication and give both users and administrators more precise control over login security.
Built-In Security Features of OpenOTP Token
Before these updates, OpenOTP-Token already included multiple layers of protection. The application provides an anti-phishing display that shows a world map comparing the source of the login request with the phone’s current location, making it easier for users to recognize suspicious activity. It also performs geolocation analysis between the last successful login and the new attempt, checking whether the distance and travel time are physically possible.
For authentication itself, OpenOTP Token supports push notifications for quick approval, regular one-time passwords for compatibility across systems, and spoken one-time passwords to support hands-free or visually impaired usage.
New Features in OpenOTP Token
1. Confirmation Code
When approving a push request, the user is now prompted to enter a short confirmation code (2 to 4 digits) shown on the login screen. The authentication only completes if the same code is entered into the mobile application.
This ensures that the user approving the request is physically at the login session and prevents accidental approvals. Administrators can also enable the confirmation code for all authentications, applying this safeguard everywhere.
2. Client Policy Selection
Mit Client Policy Selection, users must now explicitly choose the system or service they are logging into when they receive a push notification. For example, the mobile application may present three options such as Windows-Anmeldung, macOS login, or VPN.
The user must select the correct system that matches their login attempt. If the wrong option is chosen, authentication fails.
This prevents attackers from abusing blind approvals and forces the user to confirm the exact context of the login.
3. Strategies Against Simple Push Risks
Push notifications are convenient but can be misused if they are too simple. OpenOTP now includes multiple strategies to strengthen them:
- Disable Simple Push: You can disable the Simple Push feature through WebADM Client Policies and enforce a challenge-based authentication process. This ensures that even if an attacker gains access to the user’s credentials, the user cannot approve the login. Instead, the user will receive a push notification with a displayed OTP that must be entered in the client application.
- Enable the Confirmation Code Method: Enabling this method displays a code on the mobile app after the user approves the login. The user must then enter the code in the OTP challenge on the client application, adding an extra layer of security. This can be configured globally under OpenOTP or by client policy.
- Enable the Policy Prompt: When enabled, three policies will be presented in the login request. The user must select the one matching the system they are logging into. This feature requires at least three Client Policies to be configured on the WebADM server. The policies are displayed based on the “Friendly Name” setting from the client policy.
Together, these steps make push authentication more deliberate and much harder to exploit.
4. Additional Security Enhancements
Two additional protections have been added:
Mandatory Badging for Public Systems
- This feature introduces a location- and device-aware badging process that locks user access at all times unless a badge-in event occurs. Unlike a standard push, the badging system integrates with Active Directory (AD), LDAP, and Network Access Control (NAC) to provide stronger baseline protection.
- Key aspects include:
- User AD account locked by default: The directory account remains locked at the LDAP level until the user badges in.
- User network access restricted: Network access is blocked until badging is performed, with optional NAC integration.
- Policy-driven enforcement: Administrators can enforce “requires badging” at the application, group, or subgroup level, ensuring fine-grained control.
- Device-level control: User devices remain locked until a badge-in event occurs, again supported by NAC integration.
- Automatic unlocking: A successful badge-in automatically unlocks the AD account and grants network access.
- Dynamic group assignment: Groups can be populated automatically to grant rights on systems such as Unix or Samba file servers.
- Location enforcement: Badge-in events can be restricted by geographic zones or countries, reducing attack surface when no one is physically on-site (for example at night or during holidays).
- By requiring users to “badge in” before any authentication can even begin, this system reduces the exposure window for attacks such as push bombing or credential replay. If nobody is present at the office or within an approved location, no login attempts can succeed — even before push notifications are considered.
Suspicious login reporting
If a user receives a push request they did not initiate, they can reject it and block the source address for 60 minutes, automatically generating an alert for administrators.
Why These Updates Matter
These improvements directly address the weaknesses of simple push authentication:
- Accidental approvals are reduced with confirmation codes and system selection.
- Users verify context by explicitly selecting the system they are logging into.
- Phishing attempts are easier to detect thanks to maps and geolocation checks.
- Suspicious behavior can be acted upon immediately by rejecting and blocking requests.
- Administrators have flexibility to enforce the right balance between usability and security.
The latest version of OpenOTP-Token makes push-based authentication more intentional and secure. By introducing confirmation codes, system selection, and new reporting features, it ensures that users cannot simply “tap approve” without awareness. Combined with existing protections such as anti-phishing maps and geolocation analysis, OpenOTP Token now provides a robust and context-aware approach to modern authentication.
