An admirable goal it is

Trustworthy Authentication

who’s time has come…

Affirmed Identity

Providing trustworthy identity and authentication services to protect you and your organization from cyberattacks.

Affirmed Identity’s trustworthy authentication service is a cloud-based service that provides organizations with a secure and reliable way to authenticate their users. It can be used to authenticate users for a variety of applications, including web applications, mobile applications, and APIs.

Affirmed Identity authentication methods include:

  • Multi-factor authentication (MFA): MFA requires users to provide proof of knowledge, use of a device, and proof of being, in order to gain access to a system or application.
  • Risk-based authentication: Risk-based authentication uses factors such as the user’s location, use of a recognized device, proximity to other devices, and behavior to assess the risk of a login attempt.
  • Biometric authentication: Biometric authentication methods such cell phone interactions and the user’s unique behavioral characteristics to verify their identity.

Affirmed Identity offers a number of features that can help organizations to improve the security of their authentication process and authenticated sessions, such as:

  • Single sign-on (SSO): SSO allows users to log in to multiple applications using a single set of credentials. This can reduce the number of passwords that users need to remember and make it more difficult for attackers to steal user credentials.
  • User management: Assist organizations in the management of their users’ identities, access privileges and authorizations. Implements the principle of Least Privilege to ensure users only have access to authorized sensitive systems and data.
  • Continuous Security monitoring: Monitor and report suspicious activity during the authentication ceremony and throughout authenticated sessions to help detect and respond to cyber attacks more quickly.

Organizations need trustworthy authentication to protect their systems and data from unauthorized access.

Below, we discuss how Affirmed Identity not only provides trustworthy identity and authentication but as the identity provider of Zero-Trust Architecture.

  • Push – A mobile notification protocol adapted for authenticator use and best known for its simple one-tap authentication approval interface.
  • CBA – Certificate-Based Authentication, which means a public key encrypted authentication challenge is signed by a device using its private key counterpart thereby establishing a trusting bond between client and user device. Its use is a statement of possession, not one of identity.
  • FIDO – Fast Identity Online, a standard for authenticators published by the FIDO Alliance. FIDO2 is the second generation of a standard that defines an implementation of CBA.
  • FIDO-Direct– a novel adaptation of the Push like authentication but with enhanced security and benefits of FIDO2.
  • One-Time-Pad (OTPad) – a type of cryptography in which a randomly generated 128-bit AES key is used only once before being discarded.
  • AES – Advanced Encryption Standard as defined by the US government, also known as a symmetric block cipher and thought to be practically impossible to decipher.
  • One-Time-Password (OTP) – a 6-to-8-character code generated by a standard algorithm using a random secret.
  • 2FA – two factor authentication, in which one authenticator factor is supplemented by another, most commonly a password supplemented by an OTP code.
  • MFA – multi-factor authentication, which typically refers to two or more user authentication factors of the following types: something you know, something you have, and something you are.
  • MiTM – Man-in-the-middle is a type of cyberattack in which the exchange of user authentication messaging is intercepted and exploited maliciously by the attacker.
  • MiTB – man-in-the-browser is similar to MiTM, except that the browser is infected with malicious functions that intercept and manipulate user authentication messaging as it flows via the browser between the authenticator device and the relying party.
  • RC2 – AffirmID has finished development, testing, and certification and is ready for client usage as of Release Candidate 2.

99998

AffirmID Multi-Factor-Authentication Appliance | ProteqsIT
Zero Trust User Identity

Introduction to AffirmedId Authenticator

Click on More to see the video.

Zero-Trust Authentication

“Zero-Trust (ZT) Authentication” is arguably the most important component of zero-trust architecture. In 2013, a Google search for “Zero-Trust Authentication” produced less than 5 thousand hits. Today, in 2023, that same search will produce over 52 million hits. It is clearly a popular subject, and with good reason.

There are many opinions on what it is, as can be imagined. Fortunately, in light of ZT’s core principle, “never trust, always verify”, sorting fact from fiction is simple. If the authentication ceremony leaves anything to be assumed, then it is not in accordance with zero-trust identity authentication objectives.

Guides written by cybersecurity experts at CISA and NIST provide the most comprehensive descriptions of ZT architecture and authentication. The CISA Zero Trust Maturity Model is included in these guides, along with NIST SP 800-207 and NIST SP 800-63.

According to these papers, strong multifactor authentication (MFA) for identity, encrypted messaging, cryptographic authenticator devices, and authorization checks must all be part of ZT authentication. These needs and more are discussed in the following stanzas, along with explanations of how each is achieved by Affirmed Identity.

Identity

In virtually every definition of ZT, MFA is recommended to verify user identity. Both CISA and NIST recommend this. But the devil is in the details. For example, a password plus an OTP code does not meet MFA intent, it is simply two forms of “something you know”.

A biometric proof as a prerequisite during the authentication ceremony is pretty good. However, according to NIST “biometrics, when employed as a single factor of authentication, do not constitute acceptable secrets for digital authentication”.

Biometrics are fallible. Even Face ID creators acknowledge this truth, as would virtually every cyber security expert. This is also true of AffirmID biometrics. Mitigating this fact can be achieved by adding a Secure PIN known only to the user. This SPIN must be entered at biometric verification.

The biometric proves the user’s identity, and the SPIN proves their presence. Taken together, they form an impenetrable barrier to impersonation.

 

99998

Authenticator Device

NIST guidance indicates that a device is a required part of authentication: “[a]uthentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance”. They go on to clarify the device must provide “high confidence that the claimant controls authenticator(s) bound to the subscriber’s account” and that be “based on proof of possession of a key (device) through cryptographic protocols”, clarification added.

These requirements eliminate from ZT Identity considerations every known authentication protocol except FIDO2 and PIV. For Passkey there is an option for binding, referred to as attestation, but as a BYOD device the availability and use of the option is not assured and therefor Passkey is disqualified. CISA specifically calls for the use of either FIDO2 or PIV.

The meaning of “bound to the subscriber’s account” is that the authentication device is logically bound to the subscriber’s account in such a way as to be recognized, ensuring no other device can act in its stead. In addition to meeting ZT, it is essential to minimize the impact of phishing attacks. You will note the use of “minimize the impact of” and not “block all”, more on this later.

Authentication

Government sponsored standards and recommendations narrow the list of remote authenticator protocols to just one, FIDO2.

FIDO2’s Achilles heel: its unencrypted plain text protocol

The FIDO2 standard specifies a “FIDO Client” that is responsible for proofing the authenticator inputs on behalf of the Relying Party (RP). Conventional FIDO2 implementation has the FIDO Client running as a web app in a browser interacting with the authenticator via locally connected Bluetooth, USB, or NFC. The unencrypted protocol used creates a gap in security, as it allows for third-party intervention (typically a malicious app or “man in the middle” attack) during the authentication ceremony. Attacks such as this typically follow a successful phishing attack.

In an environment prone to phishing attacks, introducing an unknown Bring Your Own Device (BYOD) client device and web browser using plain text protocol encroaches on the impossibility of achieving the Zero Trust objective of “never trust, always verify.”

Recommendation

To bring FIDO2 into full compliance with Zero Trust, the protocol used between the user and RP must be encrypted, including that used over locally connected channels.

In light of MITM phishing attacks, it can be difficult to trust a BYOD FIDO Client device and browser.

Recommendation

Transfer FIDO Client functional responsibilities to the origin of the authentication ceremony, typically to the Identity Provider Service, and perform the FIDO2 protocol over out-of-band channels directly between these endpoints.

Permissions and Authorization

ZT requires all users, whether inside or outside the organization’s network, to be identified, authenticated, authorized, and continuously validated. This is before being granted or keeping access to applications and data. As a result, a trustworthy authentication process should include an equally trusted authorization service. Often, this service begins with the Identity Provider service and extends to the RP networks. Along the way, the user’s authorization and access levels may be altered depending on factors related to the authentication ceremony and session. This may, for example, be conditional based on location, proximity to or use of trusted devices, or positive results from reauthorization.

The User Perspective

tba

Account Transfer

tba
The better way in view of Zero-Trust Architecture

User Identity Verification

Done right!

Now, for this next stanza, I’m shifting into first-person discussion with a review of how it is possible to recognize you as the user of your cell phone without divulging your secrets, and to do it right without the risk of false positive conclusions, and with only a very minimal risk of a false negative.

As mentioned above, physiological biometrics (fingerprint, face ID, palmprint, etc.) are imperfect, yet they are still considered the most accurate way to recognize an individual. A better biometric alternative exists that is not restricted to a single sample, is not disclosed, and is captured and processed automatically from your (the user’s) perspective. These are biometrics derived from behavioral traits. I’ll explain one of the multiple traits we use to identify you, the cell phone use trait; there are five others processed automatically and in parallel to form an opinion of you being the same person who installed and registered the AffirmID app.

While few or any of us consider the truth of it, it’s possible to obtain a signature from the circuits of your cell phone indicative of how you use it. The signature is uniquely yours and very consistent. How you use your phone is dynamic and therefore must be learned and refreshed over time to accommodate the changes that may occur. It is not binary but rather a collection comprised of multiple data points, including three-axis device orientation, three-axis device motion, time, duration, and multiple forms of location. It is reflected in a series of high frequency events that begin with screen unlock and extend to screen lock. With time, not as much as you might imagine, this signature reaches and maintains the ability to accurately recognize that it is you who are holding and using your phone.

Cell phone use is but one of many behavioral traits used to identify you, the user, as a human unique from all others on earth. And, while it is fallible just like those from the physiological set, there are multiple mitigating characteristics. It is not a singular point of reference but a dynamic one. It is not stored and, therefore, cannot be harvested. It is dynamic, with minimal false-negative results. It is automatic. You do not have to invoke, operate, or maintain it. It is one of multiple biometrics that must work together to determine the probability that you are the person using your cell phone. This may sound terribly complex and in fact it is, but it is transparent to the user and superior to other forms of identity verification.

Something you know

SPIN

Secure Personal Identification Number

99978 To better ensure trust in biometric-based authentication, add a second identity factor. SPIN is similar to a PIN but with a security component. The objective of zero-trust authentication is achieved by adding it as a what you know second factor. The SPIN string is not stored on your cell phone or in the cloud and not disclosed to anyone or anything and thus it meets the strict definition of zero-knowledge-proof, a secret known only to you. A SPIN of just three digits is suitable for security purposes but lengths up to sixteen digits are allowed. In response to an authentication challenge the user enters their SPIN code on a virtual biometric keypad to complete the otherwise passwordless ceremony. Doing is very secure and proves four facts pertaining to user identity; the user is a human, the user is the person who installed and registered the app, the user knows the security secret, and the user indicates their intention to accept or decline the authentication offer.

SPIN security is based on its virtual keypad and related operations. A user’s first encounter with the keypad is depicted on the left. This is where tile layout templates are selected, shown here in a default layout format. There are 999 possibilities with differing degrees of complexity, from which the user picks the one they like. Moving to the right is the center keypad, where the user selects their SPIN code. The template and code assignments are one-time events during app installation. When challenged as part of an authentication ceremony, the user is presented with the right-most keypad for SPIN code entry. Tile labeling is removed, and all that’s left is a blank keypad and the user’s memory of their SPIN code tile sequence. It is during code entry that the biometrics described above are captured and used for verification.

Verifying user presence

Proximity

An additional task of identity

Identity may include proximity to a physical thing. For example, the identity of a user seeking access to a resource located remotely and accessed via laptop, client device, and VPN connection to the organization’s security zone can only be trusted if there is a way to establish the user’s proximity to the client device, laptop, and VPN connection. This need is satisfied when the device used to establish trustworthy authentication also provides a trusted indication of proximity to the client device. Doing so meets ZT need for trust in user identity combined with ZT’s other need for trust in the client device, in this example, the laptop. But there are several difficulties in doing so. For example, if the device used to provide trustworthy authentication must do so via the client device in order to facilitate access, proximity is proven at the expense of assuming trust in the client device, which is itself an excellent environment for a lurking man-in-the-middle attacker. The objective of never trust, always verify is not met.

To address this need, we provide bifurcated FIDO2 authentication. Two independent but cooperating FIDO2 ceremonies are carried out, one carried out over a Bluetooth connection between the user’s cell phone and the client device, and the other conducted over an out-of-band connection between the user’s cell phone and an identity provider, where orchestration of both ceremonies is performed to ensure uniform and uninterrupted results. The results are verification and affirmation of user identity out of reach of malicious intervention, verification of proximity of the user to the client device, affirmation of client device user identity with intervention detection and mitigation, and verification of trusted user VPN access.

Verifying user presence

Continuity

An additional task of identity

Continuity, also known as reauthentication or continuous authentication, provides proof that the authenticated person remains the same person who is actively engaged in the authenticated session.

An authenticated session may last several minutes or even several hours. A once-and-done authentication ceremony provides no assurance that the person granted access through authentication, trustworthy or otherwise, remains actively engaged in the session minutes or hours later. This possibility is not within ZT’s scope.

Requiring users to log out and log back in to reestablish confidence is both high-friction and ineffective. On the other hand, automated reauthentication with or without proximity checks is very effective at providing trusted continuity of user identity throughout the session.

As a result, reauthentication can become a hassle for the user, affecting their productivity by interrupting their flow of thought. This, however, will not occur at all or frequently where automated behavioral trait recognition is employed for user identity recognition and verification. When proximity is concerned, bifurcated reauthentication ensures the user’s presence and active engagement.

How AffirmID stacks up...

Comparisons

when compared to modern day alternatives?

AffirmIdP, AffirmID, FIDO-Direct, and support tools are an original work developed in a clean room environment absent external network connections. State of the art methods and tools were employed throughout the project with all third-party components subjected to rigorous security and performance vetting.

Patents

AffirmID components implement methods covered by US patents. All registered users are provided with a royalty-free, non-transferable license to use “AffirmID Authenticator” and/or “AffirmID IdPlz”. Along with links to privacy and license agreements, the app provides a link to that license agreement. A royalty-based license, details on request, is available to those interested in incorporating AffirmID as part of their zero-trust authentication solution.

Who should use Zero-Trust Identity and Authentication?

Only those wanting to avoid a ransomware attack.

In this section, lets explore two questions, who should adopt ZTA and how should they do it?

To answer who we must first understand why. The most convincing reason to adopt a Zero Trust model is that traditional security perimeters are no longer effective in today’s complex digital landscape. In essence, the Zero Trust model reflects today’s digital environment. It’s not just another security trend; it’s a fundamental shift in approach that aligns security practices with modern IT ecosystem challenges and complexities.

As for who should, well any organization that wants to improve its security posture should consider adopting zero-trust identity. Zero-trust identity is a complex topic, but it is important. If you are serious about improving your security posture, consider adopting zero-trust identity.

One word of caution: it should not be assumed that just because an Identity Provider Service claims to be ZT compatible that its identity regime is as well. Indeed, the IdP provider can be compliant on the one hand yet not provide ZT compliant identity on the other. This leads to unwarranted complacency and unnecessary risk. A well known IdP service fits this profile, on the one hand providing ZT compliance while on the other offering a lengthy list of different identity solutions none of which are ZT compatible.  

How can you get some?

Become an Affirmed subscriber.

Or by rolling your own.

In this section, we explore how to achieve Zero-Trust identity and authentication. As indicated above, the choices are limited. Subscribing to AffirmID is one way. The other is to roll your own, a complex and expensive choice. Just ask someone who has done it.

In the following, we explain how we did it. It’s informative for those responsible for enterprise cybersecurity. In this section, we cover what is needed and how we have provided for it.

First up are the standards, and although there is no standards certifying body yet, it is reasonable to expect one in the future. We chose to follow these standards and publications:

  • MEF 117 and 118
  • NIST SP 800-207, 800-64, FIPS-140
  • CISA ZT MM Version 2.0
  • DoD ZT Reverence Architecture Version 2.0

We considered available authenticator options based on this list’s needs and found:

  • Notwithstanding either Passkey or FIDO2, other options such as password, PIN, 2FA, MFA, Passwordless Push, and all forms of OTP are meritless in view of the above list.
  • Custom MFA authenticators represent unknowns. What is known is that MFA by itself does not meet ZT minimum requirements.
  • PIV is a viable option but registration may be problematic and expensive for many, there is a degree of user friction in its use, and deployment requires specialized hardware.
  • Passkey indicates intent with CBA and PKI. However, it fails to provide for affirmation of user identity, indication of device provenance, assurance of a one-to-one device relationship, and prevention of MITM intervention on the FIDO Client device interface.
  • FIDO2 is like its sibling in all respects except it provides device provenance attestation and a one-to-one device relationship.

Proponents of FIDO2 and Passkey are correct in pointing out there are options to the shortcomings preventing ZT compliance. In the following we show one way to take advantage of the FIDO2 options as part of a compliant ZT Identity and Authentication solution.

A closing note to this introduction relates to Identity Provider Services. Does the IdP service being used meet ZTA requirements? It’s a crucial question because ZT identity and authorization extends to and includes all aspects of the IdP services used. And from the above discussion it should be clear that an IdP’s compliance hinges in part on the authenticator technologies and implementations they utilize.

The ultimate cell phone authenticator app:

AffirmID (uh·furmd)

AffirmID is a free cell phone FIDO2 authenticator app providing the user connection to trustworthy authentication within a zero-trust architecture. Its user-friendly SPIN + tap UI verifies and affirms user and device identity without the risk false positive results. It is multi-factor authentication (MFA) with multiple biometrics for accurate user identity verification, delivering best-in-class repurpose prevention. It uses the FIDO-Direct protocol over secure GRPC channels with out-of-band per-session identifier signaling, and one-time-pad ciphers to provide strong MiTM attack prevention. Its use of FIDO2, biometric MFA identity verification, and strong encryption is in keeping with CISA and DoD zero-trust recommendations.

Learn more AffirmID Authenticator and its component from the following links.

In order to construct a zero-trust authentication system, the authenticator is essential. The usage of either FIDO2 or PIV is preferred for both Advanced and Optimal zero-trust systems, according to NIST, CISA, and DoD. They also stress the significance of using verifiable multi-factor authentication (MFA), ideally with biometrics and behavioral analytics. It is not advised to rely on cell phone screen locks for identity verification while using an authenticator, mostly because an authenticator software cannot determine the screen lock type or even if it is used, an OS restriction forced by both iOS or Android out of PII concerns.

As the interval between verification and authentication lengthens, it becomes harder to maintain trust in a validated identity. According to the three organizations, identity authentication and verification should ideally go hand in hand, with the former being a requirement for the latter. Verification of identity when using the app confers a right to use it in a present authentication session.

In addition to following these suggestions, AffirmID Authenticator requires five behavioral biometrics, including those from SPIN keypad entry, for user identity recognition. It performs the identity verification as a prerequisite to using the FIDO2 authenticator. Its use of FIDO2, CTAP2 protocol and strong user identity verification establish a verifiable bond between user, authenticator, mobile device, and user account record. In this way the full benefits of FIDO2 are realized within a zero-trust security envelope. While at rest and not in use, all internal application data is kept private and encrypted and all secrets and keys are securely stored in the security elements of the cell phone device.

The AffirmID Authenticator tackles the problem of user weariness and annoyance brought on by excessively complicated authenticators, which frequently result from security issues. By using a streamlined authentication architecture that combines a SPIN entry with a one-tap authentication acknowledgement, it avoids this friction.

AffirmIdP

AffirmIdP is key to trustworthy authentication and operates as a federated cloud or on-premises service responsible for user registration, record keeping, administration services, and authentication.

Its principal responsibility is the orchestration of authentication for local logins or for external third-party identity providers such as Azure AD, social login providers such as Google, or others implementing standard protocols such as Open ID Connect, SAML2, or WS-Federation.

Its FIDO Client service, which utilizes the FIDO-Direct protocol and operates over GRPC channels, only offers FIDO2 authentication services in keeping with its zero-trust heritage.

Learn more about AffirmIdP and its components at the following links.

AffirmIdP is an Identity Provider (IdP) service that aids in the user authentication process on behalf of a relying party. Its principal duty is to orchestrate the user authentication process and manage the user database, as well as to handle administration and maintenance needs.

There is a registration required before utilizing a FIDO2 authenticator. AffirmIdP expands on this making it a required step in the AffirmID Authenticator installation. As part of registration it creates a bond between the user, their cell phone, the AffirmID Authenticator app, FIDO2, and their email account address with their user account record stored locally on AffirmIdP server. This bond is essential to establishing a zero-trust contract.

When an authentication request is received, the user record is fetched and the FIDO2 authentication ceremony begins with delivery of the FIDO2 challenge. This ceremony displays to the user as a message inviting them to accept the authentication request. By touching “Accept,” the user confirms their intent that is codified by FIDO2’s and returning signed challenge response.

AffirmIdP provides a frontend webpage that acts as an interface for administrative operations, maintenance activities, and monitoring capabilities in addition to its basic functionality. This webpage may include functionality for maintaining user records, defining authentication settings, and evaluating proof-of-concept scenarios via an assessment-oriented user interface.

Overall, AffirmIdP functions as a full-service Identity Provider, handling user registration, authentication orchestration, user database management, and administration tools, all while guaranteeing a tight bond between the user, their devices, and their record in the system.

IdP Organization Chart – is a required and enforced relying party org chart each member of which is a registered and authorized affirmed user.

  • Owner of record – the individual responsible for the AffirmIdP relying party account and normally the individual approving establishment of the account and payments. While this user has no account access or maintenance rights, they do have the exclusive right to create, suspend, and delete the account and the right to elect and assign the account administrative super user.
  • Admin Super User – is a person with rights to all account roles except create, suspend, or delete. Among these rights is that of creating, assigning, maintaining, and removing adjunct Administrators who are granted authorization roles rights providing access to those regions which the account for which access is granted.
  • Administrators – are assigned roles and within those access rights governed by: create, read, write, modify, rename, copy, and delete. Among the roles is the ability to create and/or log on a user.
  • User – is an individual, device, or application who is granted access rights and roles created, assigned, maintained, withdrawn, and policed by and within the framework defined by the relying party.

Withing this org hierarchy there are cases where the right granted is conditional and requires authorization of the next higher level in the hierarchy. Permissions if required are requested and acknowledged using the IdPlz app.

The glue that binds AffirmIdP to AffirmID:

FIDO-Direct Protocol

Zero-trust architecture depends on its identity pillar, and its identity pillar depends on zero-trust authentication. Zero-trust authentication requires trust in every aspect of the authentication ceremony. Achieving that trust is a challenge. It requires establishing trust in every component between relying party and the authenticated individual. Typically that includes the networks, a BYOD FIDO Client device and its authenticator channels (USB, Bluetooth, or NFC), the BYOD authenticator device, and of course the user.

One alternative in a remote work environment is to deploy locked-down FIDO Client and authenticator devices. For most this is prohibitively expensive. A less expensive alternative method is FIDO-Direct. It meets never-trust, always-verify goals while eliminating the possibility of a man-in-the-middle attack as a side effect.

FIDO-Direct simplifies FIDO2 authentication by relocating FIDO Client to the AffirmIdP cloud server. It uses OpenID and OAuth2 to establish trust between the relying party or device and AffirmIdP. From there, FIDO Direct then establishes a TLS secure network connection to the users BYOD cell phone and its Latchkey FIDO2 authenticator app. Encrypting the FIDO2 CTAP messages ensures trust even though they are transferred over networks using secure GRPC or REST protocols. The cell phone security element or keychain is used to store Latchkey FIDO2 secrets, certificates, and keys.

Learn more FIDO-Direct and its component from the following links.

While it may initially appear feasible to achieve zero-trust authentication objectives by utilizing conventional FIDO2 or Passkey authenticators, the task is bound to be challenging. It is especially true when BYOD is used. Verifying the trustworthiness of a FIDO Client device of unknown province and its web browser can be challenging, for instance. Verifying trustworthiness of USB, Bluetooth, or NFC channels is essential given the CTAP protocol exchanging plain text messages. There is more but you get the idea.

To address these challenges, an alternative and more efficient strategy is proposed: relocating the FIDO Client app to the identity provider service. By doing so, all problematic components are eliminated. The FIDO-Direct protocol is suggested, which establishes a secure and trustworthy messaging channel between the AffirmIdP FIDO Client and Latchkey authenticator app on the user’s cell phone device.

FIDO-Direct implements use of secure REST or optionally GRPC using TLS 1.2 or 1.3. Enhanced FIDO2 CTAP message encryption using AES one-time-pad cyphers ensures no man-in-the-middle tampering. All communication is over stealthy out-of-band channels to further protect from man-int-the-middle.

FIDO-Direct modes include:

  • Out-of-band FIDO2 authentication.
  • Out-of-band FIDO2 authentication with parallel in-band conventional FIODO2 authentication over Bluetooth to an in-proximity FIDO Client device.
  • Continuous reauthentication and proximity verification throughout the authenticated session.
Yes, we do need yet another authenticator:

Competitive Advantages

The arrival of zero-trust cybersecurity has been a long time coming, as has AffirmID’s zero-trust Identity and Authentication. While it may seem like another authenticator app is the last thing our industry needs, in truth, this authenticator is currently in a league of its own. And where zero-trust is concerned, it has many competitive advantages.

While MFA is effective, in its generic form it fails to provide even minimal levels of trust.

Passkey is effective as a password replacement when protecting consumer social media accounts. However, it is not so much for protecting their critical PII data and corporate accounts. Its lack of verifiable user and device identity, its reliance on plain text protocols, its dependence on unverifiable FIDO Client devices, and its susceptibility to man-in-the-middle attacks make it a non-starter where zero-trust is required.

Conventional FIDO2 is only slightly better than Passkey, as it provides device identity verification. Otherwise, it suffers from all the other ailments noted above for Passkey.

There is probably no better demonstration of the need for zero-trust mutual authentication than the passwordless Push authenticator debacle of 2022. Clearly, Push authentication is untrustworthy by zero-trust standards.

A general rule of thumb is that any authenticator solution predating ZTA arrival is probably non-conformant with unverifiable trustworthiness.

TBA

Confirming IDs, IdPlz App

A recent addition to the AffirmID family is “IdPlz App.”

An app to assist in combating AI-assisted phishing, smishing, vishing, and scam attacks. A company’s CFO receives a call from the CEO directing a transfer of funds, for instance. Is it really the CEO? Perhaps, or not. Tap IdPlz to find out in real-time while on the call. Trust me on this, the CEO will not be upset.

IdPlz is an anti-scam, anti-phishing solution where the recipient of a correspondence becomes the relying party in an authentication ceremony geared not to verify another’s identity but rather to confirm they are the originator of the correspondence and to do so with the conviction only trustworthy authentication can provide.

By simply launching the app it becomes possible for a user to confirm receipt of an email, a text message, a phone call, or even a video chat. In real-time if desired. The concept is simply reversing the role of AffirmID from performing identity verification on behalf of relying parties to doing so on behalf of users.

The intent is to provide organizations a tool with which they can fight and block the growing instances of AI assisted scam/spam and phishing attacks.

Learn more IdPlz App and its component from the following links.

TBD

Confirming IDs, Portals API

Venues, security zones, boarding, ports of entry, and yes, even proofing are all tasks for which those who enter must prove they are who they claim to be. Not authentication in the conventional sense, but identity verification nonetheless.

Portals API is an extension of AffirmIdP. Hit this API with an identity verification request, and, within seconds, you will receive an indication of truth.

TBD

AffirmID Multi-Factor-Authentication Appliance | ProteqsIT

Observation Deck

Observations and opinions are this sections subject matter

tba

Attacks, Breaches, and More

Cyberattacks fortress AffirmID prevents

Here we review recent cyberattacks as they are reported with links to the original reports, brief explanation of the attack and its methods, and explanation of how those using AffirmID are insulated from it. Attacks are documented most recent first and by date.

August 10, 2023 – Takeovers of MFA-protected accounts

Corporate board members, executives, and C-row accounts were the targets, and Office 365 was the attack surface of a broad-based phishing expedition beginning in March and affecting over 100 enterprises by July. Following successful infiltration via a phishing attack, the victims’ credentials and MFA security measures are quickly compromised, giving the attacker access to all secured accounts. Microsoft recommends FIDO2 authenticators to reduce risk and improved policy management to improve detection and response.   

Corporations protected by AffirmID Fortress are immune to phishing attacks. They have no credentials, just their email address as the username to secure all accounts. Authentication is performed out-of-band and therefore out-of-reach of the attacker. AffirmID includes transparent use of single channel or dual channel FIDO2 and best-in-class user identity verification.

Tea leaves and other thoughts

Zero-trust is not a panacea. Trustworthiness is, if it can be had. Zero-trust, well implemented, is an effective way to do so.

The advanced or optimal level of zero-trust authentication requires the intimate pairing of the relying party with the authenticated user’s device, either directly or through a service. In the absence of intimacy between the relying party and authenticator device, zero-trust authentication is impossible at these levels with our without an identity service provider.

Regulation is not a matter of personal preference; it may become necessary when we consider the chaotic state of the authentication industry, markets, and deployments. The methods employed to verify one’s identity range from outdated PINs and passwords to advanced concepts like zero trust, with countless convoluted approaches in between. Amidst this disarray, we face the harsh reality of billions of dollars in annual losses, a number that continues to grow. Moreover, government agencies are aggressively pushing for zero-trust implementation in the near future as well they should. It is not hard to envision politicians seizing upon this situation, and perhaps rightfully so, as the failure to act could pose a significant national security risk.

Given the current state of the authentication industry and the pressing need for improved security measures, it is increasingly likely that the government will intervene with regulatory controls sooner than anticipated. If such regulations are implemented, significant changes will undoubtedly impact the way authentication businesses operate, potentially leading to various repercussions throughout the supply chain. As someone adept at problem-solving and willing to innovate if required, I may be less affected personally. However, it remains crucial for all stakeholders in the authentication arena to brace themselves for potential shifts and adapt accordingly.

Design principals I adhere to and believe is the KISS model: “Keep it simple, stupid.” I apply this principle to all my design efforts and have generally found success in doing so. I have even expanded upon the old saying that dates back to WWII, turning it into KISSS: “Keep it simple, secure, stupid.” There are good reasons for this.

Consider WebAuthN, a W3C standard that originated as an offshoot of FIDO and was first introduced in 2018. I became an early adopter of WebAuthN because it solved a problem while adhering to the KISSS principle. It was elegant, user-friendly, universally compatible, and overall an excellent addition to internet standards.

However, chaos ensued when everyone wanted to jump on the WebAuthN bandwagon but only if it could be revised or “compromised” to suit their specific requirements. As a result, today’s WebAuthN has become a hodgepodge of compromises, deviating from the simplicity and ease-of-use that made it great in the first place. Unfortunately, it is no longer a shining example of KISS.

Fortunately, the core functionality of WebAuthN remains intact for early adopters like myself. However, the introduction of numerous new features has introduced complexities not only in implementation but also in deployment and user experience. In a recent case, a major supplier with multiple devices offering WebAuthN capabilities implemented it differently on each device, creating a user-unfriendly experience.

In conclusion, KISSS is the way to go. It emphasizes the importance of simplicity and usability, while also prioritizing security. It is crucial to maintain these principles when developing and evolving standards like WebAuthN to ensure they remain effective and user-friendly.

Zero-trust adoption will be challenging. Moving American consumers and businesses to adopt zero-trust authentication presents significant challenges. To ensure a successful transition, it is crucial to follow the guidance provided by government agencies such as NIST, CISA, and DoD, which recommend biometric verification for user identity. In remote scenarios, both CISA and DoD specifically advocate for the use of FIDO2 cryptography, while NIST implies its importance.

Despite the shortcomings of password-based authentication, there are valuable lessons to be learned from its three decades of use that can inform the deployment of zero-trust authentication. Relying parties are accustomed to the convenience and affordability of password-based authentication, while savvy users rely on a single, long, yet memorable password for most of their accounts due to its ease and cost-effectiveness.

Undoubtedly, the task of migrating these masses, including relying parties and users, to zero-trust authentication is significant.

Implementing zero-trust authentication while adhering to the recommended guidance will likely have a moderate impact on relying parties. However, the impact on consumers will be significant due to the substantial costs associated with FIDO2 tokens, averaging around $90 per token with the need for two tokens. Additionally, consumer frustration with the possession and use of FIDO2 tokens can be expected, which may result in pushback.

In essence, deploying zero-trust authentication outside of affluent environments with the authority and resources to justify its use will pose challenges. Nonetheless, undertaking this endeavor is necessary to combat the escalating wave of cybercrimes and mitigate potentially severe cyber-related consequences on the horizon that most have yet to even see.

I see channel security as a must, regardless of zero-trust objectives. Most, perhaps all, authentication protocols employ channels for transfer of messages and do so with an assumption of security provided by the channel protocol. Where zero-trust is the goal there’s a problem with this, the word “assumption” is not in its vocabulary. There seem to be two options to bring channel security assumptions into conformance with zero-trust expectations, use of convoluted prosses to verify channel security or, use of out-of-band encryption before data goes to the channel and decryption after receipt from the channel. Indeed, agency recommendations suggest the later. Absent either of these solutions it would seem difficult if not impossible to claim zero-trust.

And how it relates: Since my first FIDO2 implementation in 2018, I’ve advocated for its adoption. That now extends to Passkey too as both are better than alternative authenticator solutions. However, in both cases, channel security assumptions are flawed. Flaws that relate to both the channel from the authenticator to the web browser and from the web browser to the relying party. Both protocols deliver to and receive from channels assumed to be secure. And they do so for messages in plain text format. This would seem to be well outside the spirit and intent of zero-trust architectures.

Credentials are what got me started down the road to AffirmID. While on a video surveillance product development project I realized their fallacy. The remote verification process forced the need for storing them remotely, more often than not in a database alongside millions of others, owned and operated by an entity unknown to the credential owner. A honey pot attracting harvesting that ultimately leads to their repurpose and reuse.

PCI DSS compliance is challenging. And although zero-trust is not yet a PCI DSS requirement in version 4.0 of the standard, it is likely to be in a later iteration. A careful study of v4.0 reveals neither anything that would raise an auditor’s suspicions nor anything that would prevent the implementation of zero-trust authentication. Indeed, those that use zero-trust authentication may find that audits go considerably more smoothly as will full adoption of zero-trust when it becomes a requirement.