Well, as we enter 2022 – and a good way into 60 years of using commercial computer technology of some sort – the password is very much alive and kicking. For example:

• This article is being written in Google Docs, which requires my username, password + MFA.  
• It will be promoted on Twitter: Username, password + MFA.
• Shared on LinkedIn. Username, password + MFA.  

Note the pattern?  Yes MFA is absolutely in the mix for me personally, but a) that doesn’t necessarily equate for all users and b) the underlying requirement for a shared secret still exists.

The “cost” to a service provider or application developer to reach out for the username and password pattern is very low.  Libraries exist and many password storage approaches now rely heavily on techniques using salts and hashes.  Making a choice for something different has some pretty big impacts – namely changes to usability and hoops to skip through regarding security change management if some new and funky passwordless approach is selected.

Drivers Towards Passwordless

However, there are emerging shoots of hope for those who wish to see a password-free world. A quick Crunchbase search reveals a tasty $700+ million has been poured into startups with the word “passwordless” in their description in the last 36 months.  A chunk of change (admittedly heavily influenced by Transmit Security’s $543 million last summer) that is empowering new techniques to the age-old problem of authentication.

The interesting aspect is that authentication is the main pinch-point of both B2E and B2C interactions.  B2E identity is having to contend with distributed working, migrations to zero trust and secure service edges and data security, whilst the continued drive for B2C consumer identity sees a need for secure yet usable user verification driven by retail and financial services and the increasing need for secure PII sharing.

All in all, user interruptions during the authentication process are increasing hugely.  The volume increases and the context surrounding the transaction is becoming more complex and subtle, too.  Usernames and passwords just won’t cut it, even with a decent MFA overlay leveraging one time passwords (generated client side of course not sent via SMS or email…) or Push Notifications.

Passwordless Requirements

Passwordless adoption requirements for both B2C and B2E will be subtly different.  It can be quite interesting to analyze requirements of passwordless just as you would any other credential – via a life cycle model.

A basic example would see steps such as enroll, use, add, migrate, reset, and remove.

Each step in the life cycle can then be broken down into the capabilities needed.  A consistent theme would seem to be a need for increased end user self-sufficiency – especially around enrollment and reset, where the dreaded call to the helpdesk instantly increases cost and reduces end user happiness.  (Obligatory sales nudge, I worked on a buyer guide for passwordless in 2021…)

B2E

From a B2E perspective, concerns for a passwordless model seem to focus upon replacing existing MFA components.  Many organisations often have numerous disconnected modals perhaps focused on specific user communities or applications.  Any consolidated passwordless approach must provide a range of application integration options from SDK’s, standards integration, or out of the box native integrations.  It would also be worth considering orthogonal authentication use cases for PAM and even physical building access.  Can that be integrated into a mobile centric passwordless approach?  The buzz words of zero trust and contextual and

adaptive access need to be shoe-horned into this landscape too, likely with a decoupled

approach to authentication away from the identity provider and network infrastructure plumbing.

B2C

Consumers are a different beast.  The focus is often upon rapid user onboarding with transparency and usability being important.  Can KYC and identity proofing be augmented into the credential issuance process?  Can those processes also be used during any reset

activities?  Clearly fraud – I’m thinking ATO, phishing, credential stuffing and basic brute force attacks – are all a huge issue with an Internet facing service, so any passwordless service needs to be immune.  Compliance initiatives such as the Strong Customer Authentication aspect of PSD2 is also driving a need for an authentication method that is secure yet can be operated at high scale by the end user.

What Are The Options?

So we all hate passwords. Service providers are getting hacked daily – the HaveIBeenPwned site is nearly at 12 billion breached accounts – and end users pick easy to break passwords that they re-use.  But, numerous startups are coming to the rescue – typically with a local mobile focused biometric (aka FaceID/fingerprint) that unlocks a private key on a device in order to respond to a challenge being set by a service that requires an authentication result.  Many do this in a proprietary way and many now leverage the W3C WebAuthn approach as a standards-based model.

A few other subtleties start to emerge.  How is the private key stored?  If on device, does it

leverage the trusted execution environment or secure enclave?  If off-device, is it stored in a

distributed manner, so no single point of failure exists?  If on device, what happens if the device is lost or stolen?  Does the end user have to re-enroll? Questions that all emerge once roll out starts to hit big numbers.

Another aspect to consider, away from just the technicalities, are things like end user training

and awareness.  Whilst many service providers aim for “frictionless” experiences and

transparency, a user journey that is too seamless, may actually make the end user suspicious – they want to see some aspect of security.  The classic “security theatre” scenario.  As with any mass rollout approach, not all users are the same. Behaviour, geographical differences, device preferences and the like will result in the need for a broad array of usage options and coverage. Can the new passwordless models cope with this?

Summary

Passwords aren’t dead, but they’re definitely quite ill.  The options for moving to something new are starting to become broad and numerous.  However, authentication doesn’t exist in a silo and on its own carries little use.  It would seem that before authentication (think proofing) and after authentication (think session integration coverage) use cases would likely emerge as the biggest competitive battlegrounds in the next 24 months.  Those suppliers that can create authentication ecosystems that integrate into a range of different devices, users, and systems

would likely see success.

Simon Moffatt is Founder & Industry Analyst at The Cyber Hut. He is a published author with over 20 years experience within the cyber and identity and access management sectors. His most recent book, “Consumer Identity & Access Management: Design Fundamentals”, is available on Amazon. He is a CISSP, CCSP, CEH and CISA. He is also a part-time postgraduate on the GCHQ certified MSc. Information Security at Royal Holloway University, UK. His 2022 research diary focuses upon “How To Kill The Password”, “Next Generation Authorization Technology” and “Identity for Hybrid Cloud”.

The post The Password Isn’t Dead…But It’s Quite Ill appeared first on IDPro.

The Golden Age

We can trace the field of Identity and Access Management (IAM) back to the creation of the password by Fernando Corbato in 1961. We’ve had to manage user accounts ever since.

Because of these user accounts, two further inventions have shaped IAM since that milestone:

• The creation of Relational Algebra ( Edgar F Codd, “A Relational Model of Data for Large Shared Data Banks”, 1970). Which led to the creation of the first SQL-based Relational Database System, Oracle v.2 in 1979;
• The creation and eventual approval of the X.500 set of standards in 1988.

These 3 inventions are still ubiquitous—33 years after the creation of the last one. Nothing new has really happened since. We still store and manage Digital Identities in Directories and/or SQL databases, and we’ve done this since Epoch.

However, the challenges of the hyperconnected modern era have shown massive cracks in these old foundations…and some companies have started to notice (I have names).

The Problem with Modern Identity

Volume

We live in a very different world today than during that famed epoch. 4.6 billion users had access to the internet as of the end of 2020, 50% of all internet traffic now goes through mobile devices, there are close to 36 Billion installed/live IoT devices this year around the world, and that number keeps growing.

Figure 1 below best summarizes this trend: the total volume of data created worldwide since 2010 and projected up to 2024.

The thing to note is that before 2010, the total amount of data stored worldwide was negligible when compared to the amount in use today.

Complexity

But data volumes are not just humongous nowadays, data has also become exceedingly complex. For instance, the Observatory of Economic Complexity (OEC) publishes data visualizations of the complexity of worldwide economic exchanges.  Figure 2 below represents an example of the data they make available:

There is indeed a relationship between textiles fabricated in China and chemicals produced in Europe. Not a “1-hop” relationship mind-you—not at all. Instead, you have to follow certain paths of products and subproducts, of interconnected partnerships and data exchanges to get from one to the other. It’s not just 1-1 or 1-N relationships anymore. No, it’s more like 1-N-N-…-N-1 these days.

Complexity arises as soon as several actors interact and start exchanging data. Complexity increases further when one starts to ponder the ways in which to protect the access to all that shared information. A good case-in-point here is the new B2B2C business model. We currently lack a truly holistic view of all the actors and resources involved in such systems.

Graphs

At this point, we have to stop and ponder the reasons why Relational Databases and LDAP Directories have been, and still are, ubiquitous in IAM. The reason is simple: both can capture the relationships that link entities together—to some extent at least.

LDAP Directories can only represent hierarchies (parent/child relationships). This in itself is very limiting, as the only way to relate any 2 objects to each-other is to create a common parent. This quickly leads to an unmanageable explosion in the number of such parents as the number of arbitrary relationships increases—exactly the cause of the infamous RBAC Role Explosion.

At least SQL Databases support all kinds of relationships. Nevertheless, they can’t cope with the sheer number of relationships that must be modelled. As mentioned above, we now have to deal with many 1-N-N-…-N-1 relationships. And as we know, joining huge tables (remember the Billions of Identities we need to manage today?) together, or with themselves (the infamous “friends-of-friends” query), many times over can bring the most advanced SQL databases to their knees pretty fast.

Not so for Graph Databases!

Graphs are simple diagrams made of Nodes and Relationships (arrows) that can actually model any data at all.

Figure 3 below is a simple Identity Graph example that depicts the relationships between 2 Identities (a User and a Client) and a Company (“Walstuff”):

A great value-added of Graphs is that they are easily readable in plain natural language, and readable by pretty much anyone. For instance, just follow the arrows in the graph above to “read the data” in plain English.

Representing data as Graphs actually solves all the problems inherent to the legacy tools we’ve been using for so long.

In particular:

Multi-Joins

Querying a Graph for an Access request for example boils down to finding a path, or set of paths, between a subject identity and the resource it tries to access. A path in the graph has the same length no matter how many other billions of nodes are stored in the database. The time it takes to process a path query is the same, regardless of the amount of data in the graph. Compare this to SQL joins. 

Data Complexity

This is better shown. 

Figure 4 below is still a simple Graph. To the Graph of Figure 3 above, we’ve now added a B2B2C partner (“InstantShop”), as well as their flagship Web App “OnlineOrders” and only 1 of their users. The result is still readable in plain English—just follow the arrows.

Now the clients of our Walstuff supermarket can also buy their products online through their OnlineOrders app. Same products, same clients, different channel. Note that employees from both sides should be able to support this new system.

Who can access what in such a model?

Please note that this is just an example and doesn’t reflect any actual IAM system. 

Ok, now try to model that in LDAP (and please email me if you find a good solution).

Conclusion

It is time for a paradigm shift in IAM. Given the challenges we face nowadays, we need data stores that can truly manage relationships, ones where relationships are true first class citizens, which can represent any arbitrary type of relationship. It is time to switch to Identity Relationship Management (IRM)! 

In the fully distributed and Identity-centric world of tomorrow, full of Distributed Identities, Consents, and Verifiable Claims, the only real way to make sense of Identities and their Entitlements is to consider them along with their relationships, in context—their context graphs.

The post The Case for Identity Graphs appeared first on IDPro.