Version Affected: 9.0.2 and below
Overview
This article explains why users with a browser fingerprint that should already be recognized are still consistently prompted for a second factor of authentication, and how to tune the Browser/Mobile Device Digital Fingerprinting (DFP) settings to resolve it. IdP versions 9.1 and above use significantly improved device recognition logic that detects browser fingerprints more accurately than the weighted scoring described below — if you are on 9.1 or later and still see this behavior, contact SecureAuth Support instead of adjusting these weights.
Cause
The Digital Fingerprinting (DFP) weights are not tuned for the environment. Each fingerprint component (browser, IP address, time zone, and so on) contributes a percentage weight toward an overall match score, and login only skips the second factor if that score meets the Authentication Threshold (95% by default). If one component is weighted too high relative to how often it actually changes, an ordinary change in that component alone can drop the score below the threshold and trigger a second-factor prompt every time.
The components and their default weights are:
- User-Agent (default weight 15%): the browser and operating system identification string. A mismatch is scored proportionally — for example, a mismatched operating system or browser name zeroes out that portion of the score, while operating system version, browser version, and other values are each scored independently within the total.
- Accept, Accept Charset, Accept Encoding, and Accept Language (default weights 3%, 2%, 5%, and 5%): the browser's declared content-type, character set, encoding, and language preferences. Adding or removing a value prorates the score — for example, adding one more value on top of 3 existing ones scores 3/4 of the full weight.
- Weight for plugin list and weight for flash font (default weights 20% and 15%): the browser's installed plugins and, where Flash is present, its available fonts. These are prorated the same way as the Accept headers above.
- Host Address/IP (default weight 15%): the client's IP address. This component can optionally require an exact match — if exact match is enabled, any IP change drops this entire weight to 0, even when every other component still matches. Because 15% is a large share of the 95% threshold, this is the most common cause of unwanted second-factor prompts.
- Time Zone and Screen Resolution (default weights 0% and 5%): scored as an exact match only — full weight if it matches, 0 if it does not.
- HTML5 local storage, HTML5 session storage (default weight 5% each), IE userdata support (default weight 2.5%), and Cookie enabled/disabled (default weight 2.5%): each scored as an exact match — full weight if the capability or setting matches what was previously recorded, 0 if it does not.
The screenshot below shows the default Weights of FP components screen, under Browser/Mobile Device Digital Fingerprinting on the Workflow tab, listing each component above with its configurable weight.
Resolution
To resolve this, adjust the fingerprint weights and thresholds under Browser/Mobile Device Digital Fingerprinting on the Workflow tab:
- Lower the Host Address/IP weight from the default 15% to 5% or 2.5%. This is the most common fix: at the default 15%, an IP address change alone can break the default 95% Authentication Threshold and force a second-factor prompt.
- Increase the User-Agent weight from 15% to 20%.
- Increase the weight of components that rarely change: Language from 5% to 7.5%, Flash Font from 15% to 17.5%, and Time Zone from 0% to 2.5% or 5%.
- Enable cookies in the browser, if not already enabled.
- Adjust the Authentication Threshold (default 95%) and Update Threshold (default 85%) — 90% is usually a good balance. Lowering these thresholds also lowers security, since it becomes easier to bypass the second factor, so balance security against convenience when changing them.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
Please sign in to leave a comment.