In Is Policy-Based Access Control (PBAC) an Authorization Model?, I argued that PBAC gets compared to Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) as if it belonged in the same category, when it actually answers a different question.

RBAC and ABAC describe what data a decision is based on: a role, an attribute. PBAC describes how that decision gets made: through a centralized policy engine instead of logic wired into the application. One is about the shape of the rule. The other is about where the rule lives and who evaluates it.

In my opinion, treating them as competing options is like comparing a recipe to a kitchen.

That distinction attempted to solve one specific confusion, but it left a bigger one untouched: PBAC isn’t the only term that gets misfiled this way.

Mandatory Access Control (MAC) and Discretionary Access Control (DAC) get compared to RBAC and ABAC too, even though they describe who administers the rules, not what the rules look like.

Access Control List (ACL) and Relationship-Based Access Control (ReBAC) show up in the same breath as “authorization models,” but one is arguably a special case of the other, depending on which paper you read.

The terminology around authorization has accumulated for decades across access control research, identity vendors, and standards bodies, and a lot of it answers different questions while using the language of a single one: “what model is this?“

This piece generalizes the model-versus-architecture distinction into a full taxonomy. Instead of asking “which authorization model is this system using?“, I want to ask five narrower questions about any authorization system, answer each one independently, and only then see where familiar labels like RBAC, ABAC, MAC, and PBAC actually land. If the terms stop competing once they’re placed on the right axis, that’s a sign the axes are doing real work.

The Core Problem of Authorization

Authorization answers one question: can this subject perform this action on this object? A user reading a file, a service calling an API, a process writing to a database. Every authorization decision reduces to that same triple: subject, action, object.

In the simplest possible system, there’s no decision to make because there’s no separation between the party asking and the party deciding. Picture your own diary, kept in a drawer in your own room. You want to read it, so you open the drawer and read it. Nobody has to grant you permission, because nobody else is involved: wanting and getting are the same act.

Real systems rarely stay this simple, because the thing being accessed usually belongs to more than one interested party. Put that same diary in a house with housemates, or move it into a company’s filing cabinet, and the picture changes immediately. Not everyone who wants to open the drawer should be allowed to, and somebody has to decide, case by case, who does and who doesn’t.

A resource server does exactly that job for software. A multi-tenant SaaS application, an internal API, a cloud storage bucket accessed by dozens of services: all of them need something that looks at a request and decides whether to honor it. That “something” is what the rest of this piece is about, and it turns out to have more moving parts than a single word like “RBAC” or “PBAC” can capture.

How an Authorization Request Gets Processed

Follow a single authorization request through a resource server and a consistent set of stages emerges, regardless of the specific technology involved: a request arrives, the server gathers context about the user and the resource, a policy evaluates that context against a rule. The evaluation produces an allow or deny decision, and the server enforces that decision by letting the request through or rejecting it.

The same five stages appear in essentially every authorization system:

1. Someone defines the rules. A developer hardcodes a check; a security team writes a policy; a resource owner sets sharing permissions on their own file.
2. The rules take some concrete shape. A conditional in application code; a JSON document; an XACML policy; a row in a spreadsheet someone exports into a database table.
3. Some data has to feed the decision. The user’s role; the department listed in a database; the time of day; the relationship between the requesting user and the resource’s owner.
4. A decision gets computed. The rule and the data get evaluated together, producing allow or deny.
5. The decision gets enforced. Something has to actually act on the result: block the request or redirect it.

These five stages map onto a vocabulary that’s been around in access control architecture for a while:

• Policy Administration Point (who defines the rules)
• Policy Information Point (what data feeds the decision)
• Policy Decision Point (where the decision gets computed)
• Policy Enforcement Point (where it gets enforced)

Brossard’s overview of ABAC architecture lays out this PAP/PIP/PDP/PEP breakdown in more detail, and it’s worth reading if these terms are new.

There’s a related, more academic framing worth pulling in here, from a 2022 systematic literature review of authorization and access control research by Mohamed, Auer, Hofer, and Küng. The paper draws a ladder with four levels: an authorization strategy (discretionary, mandatory, or hybrid) sits above an authorization model (the subjects, objects, and other components a system reasons about), which sits above an authorization policy (the concrete rule instance). In parallel, an access control model (the logic for deciding allow/deny) is enforced by an access control mechanism (the actual running software). It’s a rigorous way of saying the same thing this piece is arguing: strategy, model, policy, and mechanism are separate layers, and conflating them is where the terminology breaks down.

None of these five stages, by themselves, tells you whether a system “is RBAC” or “is PBAC.” Each stage is actually a separate question, with its own independent set of answers. That’s the seed of the classification below.

A Consistent Classification

Six axes cover the five stages above (Authorization Policy gets split from Authorization Model, since a model can be instantiated by more than one kind of concrete policy artifact). Each axis has a small number of common answers, and every familiar term (ACL, RBAC, ABAC, ReBAC, MAC, DAC, PBAC) is really an answer to one specific axis, not a label for the whole system.

A useful way to keep the six axes distinct is a metaphor borrowed from outside software entirely: the machinery of law. A legislature drafts rules, the rules get written down as statutes, courts weigh those statutes against the facts of a case, and police carry out the verdict. Swap “legal system” for “authorization system” and the same six jobs reappear below, one at a time.

Authorization Administration: who sets the rules?

Before a rule can be evaluated, someone has to have the authority to write it in the first place. That authority can be concentrated in one place or spread across many, and a system’s answer here is independent of what the rules actually say. Authorization administration can be:

• Centralized: a security team or administrator defines rules for everyone. This is the pattern behind MAC (Mandatory Access Control): access is determined by a central authority, not by the resource owner.
• Decentralized: the owner of a resource decides who else can access it. This is DAC (Discretionary Access Control): the classic “share this file with these people” pattern.
• Hybrid: some rules come from a central authority, others from individual resource owners, layered together.

Mohamed et al’s literature review treats strategy this way too, and their comparative analysis is instructive: when they classified access control models against this axis, RBAC, ABAC, and ReBAC families all landed in the hybrid category, not cleanly in DAC or MAC. That’s a useful data point on its own. It confirms administration strategy is genuinely independent of authorization model: a role-based system can be centrally administered, owner-administered, or both, and it’s still RBAC either way.

The legal system runs on exactly this split. A parliament, or a king under older systems, legislates for an entire population: centralized administration. Two neighbors agreeing on where a fence line runs, or a homeowner deciding who gets a key, is decentralized administration, closer to how contract law and property law actually work. Most real legal systems mix both, the same way most authorization systems do.

Authorization Model: what data type drives the decision?

Once the authority to write a rule is settled, the next question is what the rule actually reasons about: the specific kind of information a decision checks each time it runs. This is the axis most people mean when they say “authorization model,” and it’s the one my earlier PBAC article focused on. Here are a few common authorization models:

• Identity-based (ACL): the decision checks whether the specific subject appears on a list attached to the object.
• Role-based (RBAC): the decision checks whether the subject holds a role that’s been granted the requested permission.
• Attribute-based (ABAC): the decision checks attributes of the subject, object, action, or environment against a rule (department = “finance”, clearance ≥ “secret”, time between 9 AM and 5 PM).
• Relationship-based (ReBAC): the decision checks the relationship between subject and object, often by traversing a graph (is this user a member of the team that owns this document?).

It’s worth being honest about the fuzziness here. Depending on which academic source you read, ACL and RBAC can be described as special cases of ABAC, where the attribute in question happens to be identity or role membership. These four categories are the most useful cut for a working taxonomy, not a claim that the categories are mutually exclusive at the mathematical level.

The law makes the same kind of distinction between what a rule is actually about. Constitutional and administrative law usually define who may act by office, “only the president may sign this treaty“, which is role-based. Regulatory law more often reaches for attributes, “any business with revenue over ten million dollars must file this report“. Family and contract law hinge on a relationship: spouse, parent, business partner. And a law or injunction naming one specific person or company is the legal equivalent of an ACL. Different areas of law reach for different criteria for the same reason different authorization systems do: each criterion fits a different kind of decision.

Authorization Policy: what shape does the rule take?

Once a model is chosen, it still has to be written down somewhere as a concrete artifact:

• Hardcoded conditionals in application code.
• A structured document (JSON, YAML) loaded and interpreted at runtime.
• A declarative policy language purpose-built for authorization, like XACML, Rego (Open Policy Agent), or Cedar.
• A row in a database table.

This axis matters because two systems can share the same authorization model (both are RBAC) while differing completely in maintainability, auditability, and who’s allowed to change the rules, purely because of how the policy is expressed.

In the legal metaphor, this is simply the law itself: the actual text of the statute or code, independent of who passed it and independent of which area of law it belongs to.

Authorization Information: where does the decision-relevant data come from?

A rule is only as good as the data it’s evaluated against, and that data doesn’t all arrive the same way. It’s worth separating what the rule depends on from how the system actually gets its hands on it:

• Wired in: the data is already available in the application’s normal request flow, no extra lookup required.
• Token-based: the data arrives as claims in a JWT or similar credential, populated by the identity provider at issuance time.
• Looked up: the application queries a database, directory, or external service at decision time.
• Environmental: the data describes the context of the request itself rather than the subject or object: time, location, device posture, network.

This is a place where even careful academic treatments blur a real distinction. Mohamed et al’s framework folds environmental attributes into the authorization model’s component list, alongside subjects and objects, rather than treating “where does this data physically come from at runtime” as its own architectural concern. I think that’s a small version of the same mistake the PBAC article calls out: knowing that a decision depends on “time of day” is a modeling question but knowing that the request has to make a network round-trip to a directory service to get it is an architecture question, with real consequences for latency and failure modes.

A courtroom depends on the same kind of input: facts and events. Testimony, documents, timestamps, prior records. The same law applied to a different set of facts produces a different verdict, exactly the way the same policy applied to different token claims or different database lookups produces a different authorization decision. And, just as in an authorization system, where those facts come from (a witness on the stand, a document requested via subpoena, or an expert report) is its own separate concern from what the law says.

Authorization Decision: how and where is the decision computed?

Once a rule and its data are both available, something has to actually run the evaluation. That “something” can live in a few different places, and where it lives is a question about architecture, not about the rule itself:

• Wired into application code: an if statement or a framework-native permission check inline with the business logic.
• A dedicated library or module: decision logic factored out but still running inside the application process.
• A centralized policy engine: a separate service that receives context and returns a decision, often shared across many applications.

PBAC lives here, not on the “authorization model” axis. Centralizing the decision point into a policy engine is an architectural choice about where evaluation happens, and it’s compatible with any of the authorization models: a PBAC engine can evaluate role-based rules, attribute-based rules, or a mix. That’s exactly why PBAC isn’t a peer of RBAC and ABAC. It’s an answer to a different question than the one RBAC and ABAC answer.

This is where the courtroom metaphor lands squarely: a court, and specifically a judge, is the decision engine. The law and the facts go in, a verdict comes out. And a legal system’s habit of routing different kinds of cases to different, specialized courts (traffic court, family court, a supreme court) without changing what the underlying law says is a good picture of what PBAC actually is. It’s a choice about which court hears the case, not a change to the law itself.

Authorization Enforcement: how and where is the decision enforced?

A decision only matters if something acts on it, and that action doesn’t have to happen in the same place the decision was made. Authorization enforcement can live in:

• Wired into application code: the same code path that made the decision also acts on it.
• Dedicated middleware: a framework-level component intercepts the request based on the decision.
• Distributed enforcement: a gateway, sidecar, or proxy enforces decisions at the network edge, independent of the application itself.

Like the authorization decision axis, this is architecture, not model. A system enforcing ABAC decisions through an API gateway and a system enforcing ABAC decisions through inline middleware are both, unambiguously, ABAC. They just made different choices about where enforcement lives, usually driven by concerns like operational scale or the number of services that need to share one policy.

This is the police, in the metaphor: the verdict gets carried out regardless of whether that happens inside the courtroom or on a street corner miles away. The court decides; the police act. It’s the same separation between authorization decision and enforcement in an authorization system.

Putting it together

A real authorization system’s full description is a tuple across all six axes, not a single word. “RBAC” says something about the authorization model axis and nothing about the other five axes. An authorization system can have:

• Centralized administration (MAC)
• Role-based model (RBAC)
• JSON policy documents
• Token-based information
• A shared policy engine (PBAC architecture)
• Gateway-level enforcement.

That’s a coherent, common real-world setup, and every label in it is accurate simultaneously, because each one answers a different question. The confusion in most authorization discussions comes from picking one label per system and treating it as exhaustive, when it’s really just the answer to whichever axis happened to come up first in the conversation.

The legal metaphor running through this section is useful precisely because it breaks down in the same places the software terminology does. Nobody would call a law court an “administrative law” or claim the existence of a “witness-based law” because a judge renders a verdict considering the deposition of a witness. But the six jobs underneath it (who legislates, what kind of law applies, what the law actually says, what facts it’s applied to, who judges, who enforces) are as separable in a courtroom as they are in a policy engine, and confusing them causes the same kind of category error either way.

Conclusion

The terminology problem in authorization isn’t that the field lacks vocabulary. If anything, it has too much: MAC, DAC, RBAC, ABAC, ReBAC, ACL, PBAC, and more, each coined by a different paper, standard, or vendor, at a different layer of the same request lifecycle. The problem is a habit of treating all of it as one flat list of “authorization models” to choose between, when most of these terms don’t compete with each other at all.

Separating the questions helps in a very practical way when you’re actually choosing an approach for a real system: pick the authorization model based on what your access rules naturally depend on (roles, attributes, relationships). Separately, pick the architecture (where decisions get made and enforced) based on your operational constraints (how many services need to share policy, how much latency you can tolerate, who needs to audit or change rules). Those are two separate decisions with two separate sets of tradeoffs and bundling them into a single choice (“we’re doing PBAC” or “we’re doing RBAC“) tends to hide half of what actually needs deciding.

None of this makes the individual labels wrong. RBAC is a real, useful description of a model. PBAC is a real, useful description of an architecture. They’re just not describing the same thing, and a consistent classification is what lets you say precisely which thing each one is.

References

• Is Policy-Based Access Control (PBAC) an Authorization Model?
• A Taxonomy of Modern Authorization Models
• The State of the Union of Authorization
• A systematic literature review for authorization and access control: definitions, strategies and models. International Journal of Web Information Systems, 18(2/3), 156-180. https://doi.org/10.1108/IJWIS-04-2022-0077

Andrea Chiarelli is a Principal Developer Advocate at Auth0 (Okta). He has extensive experience in software development, holding various technical roles. In recent years, he has focused on Identity, developing a passion for the core concepts, which he aims to disseminate to developer communities.

The post Authorization Terminology is a Mess: Let’s Fix It appeared first on IDPro.

The promise of attribute-based access control (ABAC) is positively mesmerizing. Most IAM products can assign access based on roles and rules built on user data. Training usually provides simplistic, easy to follow use cases. Business analysts can quickly analyze data and sort out use cases for automation which should improve security, lower overhead, and enable the business. While this all sounds great, and is great, a lot of online and product documentation leaves out a key component – data stewardship. If the departments that own the data don’t know how it is being used, and agree to it, side effects of automation may ensue leaving users without the access they need, and the IAM, Sec Admin, Access Admin groups in SOS mode. Here is a cheat sheet that lays out definitions, benefits, and potential “gotchas” organizations should be aware of before launching their ABAC initiative.

Data Requirements for Implementing Attribute Based Access Control (ABAC)

• Data Stewards – responsible for each data element used in ABAC
• Data Integrity – with established accuracy and completeness thresholds
• Understanding of Use – and acceptance of the use of the data by the data owner and provider
• Data Protection – changes to data objects and available data values must be governed,
• controlled, documented and communicated

ABAC Benefits

• Automation for access decisions and provisioning based on data – business enablement
• Ability to map data to business roles to access in systems and applications
• Improved security posture and better housekeeping
• Bundling of access into roles

ABAC Concerns

• Missing or incomplete data requires fallback to default logic for error handling
• Timing – data may change for a worker before or after the true date when action should be
• applied to worker accounts
• Point of failure when logic is dependent on specific data values that can change based on
• Finance, HR, Org changes – such as or Cost Center or Org Name changes
• Potential for changes to large numbers of worker records simultaneously
• Retesting – Upstream changes require updates to IAM system and retesting
• Finance and organization data changes may not be communicated to IT and identity teams in
• advance, resulting in downtime or fallback to default logic

Funnily enough, a quick Internet search for “RBAC is dead” will reveal a trove of articles on the rise of ABAC.

James Dodds

IDPro Editorial Committee

A Look Back at GDPR and A Look Forward to CCPA and LGPD 

What can we learn from GDPR (the General Data Privacy Regulation) about how to manage privacy legislation? What does impending privacy regulation like CCPA (the California Consumer Privacy Act) or LGPD (Lei Geral de Proteção de Dados, Brazil’s personal data protection law) mean for the privacy landscape in general? How can we future-proof our privacy practices to move beyond prepping for the next set of rules?

GDPR is now a year and a half old! I will always remember the day GDPR was born, as it was preceded by 800 companies I don’t remember ever interacting with sending me emails asking me to approve their updated privacy policy. It also marks the era of cookie notifications on every website, each of which with an “accept” button but no “decline” button. It’s the same behavior as when I’m offered cookies at my mom’s house, so I’m actually pretty used to it. You’re gonna accept these cookies and you’re going to love them!

Seriously, though, GDPR is a positive step. It is a major legislative piece that tackles the issues of data rights and consent for a big group of people and it represents that people are demanding more control over their data. This can feel daunting for marketing teams, who have to make sense of all of these rules and may feel like they are losing their ability to generate leads. And that can be true in the short term – but the effect in the long term is that companies will start to have more genuine relationships with those who remain, and the ability to really develop a trusted relationship with those customers results in greater customer loyalty and a higher lifetime value. But, before we get into that – let’s take a look back at GDPR over the last year and a half.

So what’s happened?

In the first year:

280,000+ cases

144,000+ complaints

89,000+ data breach notifications

90+ fines

56,000,000 Euros in fines

To date:

200+ fines

460,000,000 Euros in fines

(Reference: https://enforcementtracker.com/)

As a reminder, the GDPR gives national watchdogs extensive powers to investigate privacy breaches and to hand down fines of up to 20 million euros (around $22.4 million USD) or 4 percent of a company’s global annual turnover, whichever is greater.

More than 280,000 “cases” were reported in 27 european economic area countries in the first year of the GDPR. Of these, around 144,000 were “complaints” (e.g. improper data processing), as opposed to 89,000 that were data breaches (i.e. insufficient measures to secure data).

As of this writing, the top complaint category is insufficient legal basis for data processing, by almost twice the number of fines of any other category. In total, 460 million euros in fines have been levied (which is more than four times the amount of fines just six months ago!)

This sounds like a significant number, but it turns out that more than 400 million of that is British Airways, Marriott, and Google. British Airways and Marriott were fined around 200 million and 110 million, respectively, for insufficient technical and organisational measures to ensure information security, and Google was fined 50 million by CNIL [ke-nil] (France’s privacy regulatory body, the Commission Nationale de L’Informatique et des Libertés) for failing to inform users adequately about its use of their personal data and failing to seek “valid legal consent” from users to personalize ads. 

Now, that leaves 60M euros over 200 fines levied, and some of you might be thinking to yourself – okay, 300,000 Euros, and only 200 organizations have been fined. Maybe there’s a risk discussion we need to have before investing any further in privacy. But, don’t get too comfortable, because it turns out regulators aren’t letting things slide, they’re just really, really busy. As DLA Piper research puts it:

“Regulators are stretched and have a large backlog of notified breaches in their inboxes. [T]he larger headline grabbing breaches have taken priority …, so many organizations are still waiting to hear from regulators whether any action will be taken against them …”

which means that, as Giles Watkins, IAPP Country Leader for the UK explains:

“… I sense that there is only a limited time for organizations to put their houses in order before the commissioner does revert to the enhanced penalty regime, with potential enforcement actions perhaps being even more significant to businesses than the monetary fines” – Giles Watkins, IAPP Country Leader, UK

Okay, great, so we really do have to care about this. But . . that’s not all. We don’t just have GDPR to worry about: every country and their mom are coming out with a privacy regulation. Are we going to be living a GDPR Groundhog Day for the rest of our lives?

Not necessarily – but first, let’s talk a little bit about what’s definitely maybe coming and how these regulations overlap.

The next big regulation to hit the scene this year is the California Consumer Privacy Act, the CCPA. This law has been called GDPR-lite or the California GDPR, which I think just means it’s privacy regulations with some avocados on it? I kid. In all seriousness, though, there are some differences between the two, which we can take a quick pass through.

Both regulations require transparency or audibility of operations. Both require maintaining a data privacy notice, policies and procedures for obtaining consent. However, the CCPA notice

requirements on personal information disclosed or sold to third parties only covers the 12 months preceding the request

CCPA is specific about the ability to opt-out of the sale of personal information to third parties as well as protecting those users from price or usability discrimination, while GDPR is not as explicit about that particular scenario.

CCPA 1798.115 (d) A third party shall not sell personal information about a consumer that has been sold to the third party by a business unless the consumer has received explicit notice and is provided an opportunity to exercise the right to opt-out pursuant to Section 1798.120.

The high level take away from this comparison, is that we should expect to have to grant users the right to manage their data in a variety of capacities. So, what does this look like when we add in LGPD?

The high level take away from this comparison is that we should expect to have to grant users the right to manage their data in a variety of capacities. So, what does this look like when we add in LGPD, another major privacy legislation to appear post-GDPR?

The LGPD is very similar to GDPR in terms of personal data rights and protections – in each of the major categories we examined for GDPR, LGPD follows suit exactly. There are some minor differences with the LGPD. For example, LGPD does not differentiate anonymous data from pseudonymous data. When the difference between those categories is related to risks of re-identification of the data subject, the Brazilian law does not relax legal obligations for controllers that employ pseudonymisation techniques when compared to the EU regulation. But, on the whole, similar data strategies and rights considerations can be employed between the two.

So what are we going to do? To hit the overarching themes and impetus behind the regulation, every organization should do three things:

1. Understand your customer data
2. Make it easy (ish) to manage
3. Give control to your customers

In order to understand your data, you need to:

• Catalog your data: What data do you have? Where is it stored? Why do you have it/how is it used?
• Know who can see your data: Who can access your data? To which third parties do you share/sell data and what data do you share/sell?
• Assess your risk: What is the sensitivity of each piece of data?

In order to manage your data you need to:

• Minimize Data: Determine what data is needed and what isn’t – delete data you don’t need, anonymize data you don’t need to tie back to an individual
• Data Retention: Based on your catalog decide how long you need each piece of data and implement process around retention and disposal of data
• Data subject processes: Make it as easy as possible to respond to requests like: portability, vendor sharing/selling, deletion, processing by having APIs or processes in place with each data owner
• Review/Enhance Security: Protect data from unauthorized access, use classification to drive access

Finally, giving control to your customers means:

• Transparency: Show your customers how you’re using their data and with whom it’s shared/sold. Give them the ability to revoke those purposes or third party access
• Data Access Rights: Give your customers the ability to exercise data rights like portability, restriction of processing, right to be forgotten. The more automated, the better.
• Consent and Preferences: Give your customers the ability to opt into or out of data uses (as much as is possible) and establish their own preferences for communication and data use.

Doing this will not only keep regulators happy and your organization off the fine list, it will also create a trusted, transparent relationship between organizations and the data subjects whose data they are stewarding, which means these regulations, if handled well, can be a win-win for both organizations and customers, consumer, and all data subjects.

Marla Hay

Sr. Director

Product Management – Privacy & Data Governance

Salesforce

Evaluating 2FA in the Era of Security Panic Theater

It seems like today’s world offers constant reminders of how insecure our digital lives can be. As a security professional, part of my job is to monitor for threats to my company and the organizations with which I have a relationship. A significant part of that effort lies in assessing how likely or realistic those threats are. If you believed every infosec vulnerability headline you see come across twitter, it would be easy to feel somewhat like chicken little, with the sky ever falling. I’ve actually coined a term for this phenomenon (though I’m not sure if I actually originated it, but Google seems to think so): Security Panic Theater.

If this term sounds mildly familiar, it is because of its proximity to the phrase ‘security theater’. We experience this pretty regularly whenever we attend a major sporting event like the World Series and we have to go through long lines where people wave a wand over us to ensure my keychain knife doesn’t get admitted to the stadium. This takes place even though the track record of seizing weapons that would matter is pretty poor. But the mere act of this experience makes patrons feel safer. This is even worse when we travel and pass through TSA’s gauntlet of screeners. Consistent penetration tests reveal a woeful rate of actually detecting items that could cause us harm while we are in flight. To add to the insult of this process, there is a comic reality with what actually is seized. I’ll let comedian Steve Hofstetter explain:

If you bring too much liquid, the TSA confiscates it and throws it away, in case it’s a bomb. So they throw it away. In case it’s a bomb. In the garbage can, right next to them. With all the other possible bombs. In the area with the most amount of people.

In case it’s a bomb.

Security Panic Theater (SPT) is a bit of a different experience. The process for SPT goes something like this:

Vulnerability/breach announced regarding a product or control (x) [Security]

+ Inflammatory internet headline(s) regarding (x) [Panic], which leads to the conclusion:

Product or Control (x) is useless/defeated [Theater]

A relatively recent example of this was the release of a penetration testing toolkit by Polish researcher Piotr Duszyński named Modlishka, which loosely translates in English to Mantis. The central feature of this toolkit was the use of a reverse proxy that could accelerate a phishing flow by sending a user to a spoofed URL, but the rest of the web experience was as the user expected. This enabled a man-in-the-middle (MITM) attack to capture both the credential and the SMS code being used by the user.

The significance of this new framework didn’t lie with the fact that you could now phish any 2FA method that used OTPs. What made this release notable was that it was now significantly easier to accelerate the phishing flow because you didn’t have to spin up a fake site. A reverse proxy would do the work for you. To be clear, that is certainly noteworthy, but also not new.

However, to hear the twitterverse and online media outlets talk about it, you’d think all our credentials, even if protected by 2FA, were suddenly moments away from being captured by hackers. Now, to be fair, there are some responsible journalists who try to treat these topics fairly, but even a sane article can often be overridden by a clickbait title like “Is 2FA Dead?”

Let’s get a few basics clear for the sake of sanity & clarity:

1. 2FA can’t be killed . It isn’t a combination of factors for authentication, not a single technology or pattern. The last few years alone have had a litany of episodes where a particular technology may be at risk (often temporarily, or misleadingly so), such as:
   1. RSA tokens were allegedly cracked (mostly not true)
   2. SS7 flaw will drain all your bank accounts (true, but hard to implement)
   3. NIST Killed SMS 2FA (sort of, but not really)
   4. Modlishka makes SMS useless (sort of, but not really) 
   5. Google Security keys have Bluetooth flaw (recall for some, not all)
   6. Yubikey FIPS keys flawed (recall for some, not all) 
   7. Apple promoted modifications to SMS 2FA for improved anti-phishing strength & joined FIDO’s board. 
   8. 2FA implementation in Iowa Caucus renders app nearly unusable 

Notice the trend here? While there is some truth for most of these from a vulnerability perspective, the reality is that these technologies still work to protect your credentials. Apple’s recent announcement has its own debate worth talking about (and has been on IDPro’s Slack site) and the debacle in Iowa shows that any technology is a dumpster fire waiting to happen if its implementation is designed poorly.

1. The diversity of the 2FA landscape makes it stronger, not more vulnerable. 

Let’s take a look at the following categories of authentication: 

Pretty diverse to be killed with a single vulnerability, I would think! Now let’s overlay which ones have at least one known vulnerability:

If we look at all the ones in red, that would be pretty disheartening to the casual observer. That’s where journalists and analysts need to take special care in talking about vulnerabilities. The real story doesn’t fit neatly into a simple headline regarding the vitality of the authentication landscape.

1. All methods of 2FA are still incredibly effective (some more than others) 

Google published a study of some internal findings on various methods used to secure their public credentials. Yes, SMS should be the low hanging fruit of 2FA but guess what, even this well-beaten pinata of 2FA stopped 76% of targeted attacks and nearly 100% of automated & bulk phishing attacks!

Microsoft recently published some numbers to similar effect, that the risk of account compromise is reduced by 99% using multi-factor authentication (MFA). I’d say 2FA is far from dead in that context.

1. Yes, we should get rid of the 2 in 2FA, long live MFA

The biggest reason for this is that users can be more secure, and less inconvenienced when they have access to multiple ways of authenticating instead of one token combined with a password that can be lost, or a phone that can be upgraded and lock a user out. Without promoting one vendor, I can say thoughtfully that I have several methods to secure my key accounts and that diversity of options, I believe, is the key to giving our users the power of choice as to how they want to login. That power is how we eventually do reduce passwords to an edge use case. The key is that more sites need to support those methods to incentivize adoption. We’re not there yet, but the last few years show a lot of promise in eventually achieving that goal.

The reality is, even the coolest methods of authentication will eventually find a vulnerability. History proves this. But we don’t throw the baby out with the bathwater when those are discovered. We fix it, learn from it, and stay secure. Let’s leave the theater to the actors, where it belongs.

Lance Peterman

IDPro Board

Resources:

• https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu 
• RSA Paper – https://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf 
• Modlishka Introduced- https://blog.malwarebytes.com/cybercrime/2019/01/two-factor-authentication-defeated-spotlight-2fas-latest-challenge/ 
• SS7 – https://www.wired.com/2017/05/fix-ss7-two-factor-authentication-bank-accounts/ 
• NIST SMS – https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/ 
• NIST SMS 2 – https://www.zdnet.com/article/nist-blog-clarifies-sms-deprecation-in-wake-of-media-tailspin/ 
• Modlishka – Mitigation approaches https://www.cert.pl/en/news/single/recommendations-on-mitigation-of-man-in-the-middle-phishing-attacks-evilginx2-modlishka/ 
• Google Security Keys recalled – https://www.engadget.com/2019/05/15/google-recalls-some-titan-bluetooth-security-keys 
• Yubico FIPS Recall – https://www.theregister.co.uk/2019/06/13/yubi_key_bug/ 

The post IDPro Newsletter – Feb 2020 appeared first on IDPro.

The post Your name in the IDPro Body of Knowledge fame appeared first on IDPro.