Tag Archive for: phishing-resistant authentication

Most sign-in setups were built one control at a time. A password came first, a text code was added later, and a single sign-on layer arrived when the number of applications grew. Each addition closes some risks and leaves others open. The useful question is not whether a bank has MFA. It is which sign-in risks the current setup covers, and which it leaves open.

Sign-in attacks, the controls that counter them, and their limits

The table maps the common sign-in risks to the control general practice uses for each, and to the OmniDefend capability that covers it. The last column shows where that control stops, so no row claims more than it does.

Second factors that resist phishing and SIM swapping

A second factor is only as strong as the attack it resists. A one-time code that a person types into a website can be captured by a page that looks like the bank’s. OmniDefend’s explainer on bypassing 2FA describes this pattern, in which attackers use convincing fake login sites that ask for the username, password, and 2FA code. For example, a customer gets a text that looks like it came from their bank, follows the link to a page that copies the login screen, and types in the code they receive. SMS codes carry a further weakness: a SIM swap can move the customer’s number to an attacker’s device, which then receives the codes. Phishing-resistant options bind the proof to the site. NIST guidance recommends phishing-resistant authenticators for high-value accounts, according to a secondary summary by D3RX.

OmniDefend’s customer identity offering lists multi-factor identification among its capabilities, which is the layer that manages which factors a customer uses and how they are checked. For a comparison of the factor types, read our post on types of MFA used in online banking. For why codes entered on fake pages fail, read phishing-proof MFA versus standard MFA.

Password-less sign-in and origin binding against lookalike sites

A password-less login replaces the password with a key pair held on the customer’s device. The browser ties each credential to the website it was created for, so a copy of the page on another domain cannot use it. That origin check is the main reason this approach resists phishing, and it is the general behavior of passkeys under the WebAuthn standard.

OmniDefend lists a password-less website option, described in its materials as a way to offer password-free login and secure e-commerce transactions. What it changes for a customer is the sign-in step: a fingerprint, face, or device prompt instead of a typed password. For example, a shopper confirms a purchase on a store’s site with the fingerprint sensor on their phone rather than typing a password they might have reused elsewhere. What it does not change is the device itself. A customer who loses control of an unlocked phone is still exposed. Our post on passwordless authentication and how it works covers the mechanics in more depth.

Single sign-on for staff: one identity provider as an attack target

For staff, the risk is less about one login and more about how many logins there are. Single sign-on lets an employee authenticate once with an identity provider and reach several applications. For example, a clinic administrator signs in once in the morning and opens scheduling, billing, and the document store without a separate password for each. Because one identity provider sits in front of several applications, its configuration decides what each connected application trusts. That makes it the point of concentration, so it needs its own MFA and its own audit trail.

OmniDefend’s workforce offering lists single sign-on, multi-factor authentication, a universal directory, and auditing and reporting. Checks worth running for administrator accounts:

• Every application that accepts staff sign-in is listed against the identity provider, not configured separately.
• MFA is enforced for administrator accounts, not only for ordinary users.
• Confirm that removing a person from the directory ends their access to each connected application, since each application may be connected differently.
• Sign-in events from the identity provider are retained and reviewed.

For the wider case, our workforce identity management guide and our post on how single sign-on works explain the design in more detail.

Account recovery and session takeover after sign-in

A sign-in check runs at one moment. Account recovery is a separate route around it. OmniDefend’s explainer notes that attackers can use personal data to convince support staff to reset a password or deactivate 2FA. For example, a caller says they lost their phone and asks the help desk to remove the second factor, which is exactly the request an attacker would make. The session that follows sign-in needs its own protection, because the same explainer describes reverse proxy malware that waits for a login and then takes over the session. Our post on how hackers bypass 2FA describes these routes, and MFA fatigue and how to respond covers push prompts that are approved under pressure.

Testing your sign-in controls against these attacks

Take the four risks in the table and check each one against your own setup. For every row, find the control that is actually in place, and whether it applies to the account types that matter most. A row with no control, or with a control that only covers some accounts, is the one to fix first.

OmniDefend offers a 30-day free trial, and our sales team sets it up for you, so the test runs on your accounts rather than on a demo environment. If you would rather see the capabilities first, you can request a demo. Start with the 30-day free trial and check the table row by row.

Frequently asked questions

• Does MFA stop every phishing attack?

No. A second factor that a person types into a fake page can be captured. Phishing-resistant factors that bind to the real site are harder to abuse, which is why general practice moves toward them.

• Is a password-less login safer than a password with a code?

For phishing, usually yes, because the credential is tied to the site. It does not protect a device that is already unlocked by someone else, and account recovery still needs careful design.

• Why do staff need MFA if single sign-on already checks their identity?

Single sign-on centralizes sign-in, which makes the identity provider the most valuable target. MFA on that provider is what stops a stolen password from opening every connected application at once.

• What happens to access when someone leaves the company?

Whether removing someone from the directory ends their access depends on how each application is connected. Applications outside the directory need separate removal.

Resources

• Trail of Bits, The cryptography behind passkeys (WebAuthn origin binding)
• D3RX, NIST SP 800-63B summary (phishing-resistant authenticators, secondary)
• ThreatDown, What is credential stuffing?
• Ampcus Cyber, What is credential stuffing (NIST SP 800-63B-4 password screening, secondary)
• OmniDefend, How hackers bypass 2FA
• OmniDefend, Phishing-proof MFA versus standard MFA
• OmniDefend, MFA fatigue: what it is and how to respond
• FFIEC Authentication and Access to Financial Institution Services and Systems (2021), via FDIC FIL-55-2021
• OmniDefend, product listing for customer identity and workforce capabilities