CIAM
Thought Leadership
CIAM
Thought Leadership
Resources
Blog
What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right
CIAM
Thought Leadership

What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right

Written By
Published On
Dec 11, 2021

Listen to the following security and product experts share their insights in the webinar:

  • Tom Field, Senior Vice President of Editorial with Information Security Media Group
  • Jing Gu, Senior Product Marketing Manager with Beyond Identity
  • Jamie Hughes, Product Manager with Beyond Identity. 

Transcript

Tom

Hi there. I'm Tom Field, Senior Vice President of Editorial with Information Security Media Group. Very pleased to welcome you to today's webinar, which is entitled "What Brands Get Wrong About Customer Authentication." Got two presenters for you today. They're Jing Gu, Senior Product Marketing Manager with Beyond Identity, and she's joined by Jamie Hughes, Product Manager with Beyond Identity. 

Now, before I bring Jing and Jamie onto the camera here, let me give you a little bit of background on what we're going to talk about today. Customer authentication is a critical component of almost every application that exists because it serves as a product gateway, impacting 100% of customers. While it's a standard feature, it's not easy to get right, and the stakes for getting it right are higher than ever. 

Forty-six percent of customers abandon a transaction because of authentication and account takeover fraud increased by a whopping 292% in 2020. So join us as customer authentication experts shed light on the latest findings from research and customer authentication, discuss some common misconceptions, and present effective solutions to significantly increased security without increasing friction. 

A little bit of background on my organization, Information Security Media Group. We're a global education and intelligence firm, we're based in Princeton, New Jersey. You might know us by one of our 34 media sites. These include BankInfoSecurity, HealthcareInfoSecurity, and DataBreachToday. In all, we reach an audience of 950,000 security leaders around the world, and we give them a daily diet of news, analysis, research, events, and educational programs just like this one. 

A few notes of housekeeping, if you have any questions for Jing or for Jamie during the course of this session, you can send them in anytime. Might not be able to get to everyone but, those questions that we can answer today, we will get responses back to you via email. If you should encounter any technical issues while viewing today's webinar, please take down the email address on your screen. If you write to webinars@ismg.io, we do have technical support staff standing by to help. 

Also do need to state today's webinar is copyrighted material. It's meant for today's session and individual study purposes only. If you'd like to use any of the information that's presented today, or if you're looking for customized training materials, please contact us. So I'd like to introduce our sponsor today, Beyond Identity. 

Headquartered in New York City, Beyond Identity was founded by industry legends Jim Clark and Tom Jermoluk to eliminate passwords and radically change the way that the world logs in, without requiring organizations to radically change the technology stack or processes. Funding by leading investors include Koch Disruptive Technologies and New Enterprise Associates. 

Beyond Identity's mission is to empower the next generation of secure digital business by replacing passwords with fundamentally secure X.509-based certificates. This patent-pending approach creates an extended Chain of Trust that includes user and device identity in a real-time snapshot of the device's security posture for adaptive risk-based authentication and authorization. 

Beyond Identity's cloud-native solution enables customers to increase business velocity, implement new business models, reduce operating costs, and achieve complete passwordless identity management. To learn more, please visit beyondidentity.com. And please, let's meet our speakers today. 

Jing Gu leads product marketing for Beyond Identity's customer authentication solution, responsible for driving its awareness, adoption, and growth, with an emphasis on enabling a robust developer community. Prior to Beyond Identity, she formed and led the product marketing function at Shutterstock, focused on delivering developer tools and integration products. 

When not evangelizing frictionless authentication and secure passwordless authentication, she enjoys exploring New York City, hiking, and reading. Jamie Hughes has spent the past five years for early-stage identity and Access Management companies helping to drive success in the EMEA region. His Software/DevOps Engineering background gives him the ability to advise and enable clients on all things identity with a strong focus on customer or consumer identity management. He's Product Manager today with Beyond Identity. With that, let me bring aboard Jing and Jamie. Folks, let's have a conversation about identity. Let's start here. 

Jing, set the scene, what's happening in the world today that makes it a business imperative to get customer authentication absolutely right out of the gate? 

Jing

Yeah. For sure. So customer authentication drives revenue, ultimately, right? It's not just about risk mitigation, it's not just about fraud prevention. But authentication, as you mentioned in your intro, touches 100% of your acquired customers. And guess what? Acquiring customers is really difficult, keeping them around is really difficult, and you don't want people to hit a login page or registration just to drop off. 

So there's a few ways our customer authentication drives revenue. The first is conversions at registration, login, and recovery. All those are critical steps in the customer journey, and any friction in those steps causes customers to leave your application, and sometimes they don't come back. 

And the second thing is customers nowadays are more skeptical than ever. And when they hear of a breach, or a fraud, or if that happens to them, they're not going to use your service again. Actually, according to research, 68% of consumers have stopped using our service because of a breach, even if the breach didn't happen to them directly. 

So it's about long-term trust and reputation of your business. And lastly, customer authentication sometimes, you know, people have authentication built on Legacy OAuth infrastructure, but in today's world where everyone is transacting and interacting online, digital transformation is extremely critical. And organizations with higher digital maturity recognize a 45% higher revenue growth. 

So in these three ways customer authentication, getting it right nowadays is not a negotiable part of your business strategy. 

Tom

So, Jing, when you take a step back, customer authentication is a fairly standard feature, and yet no one's really happy about it. On the company's side, passwords are highly vulnerable to attacks and it turns out that consumers are not really satisfied with that either. What does your research say about how consumers feel about their authentication options because they feel more strongly about it than ever? 

Jing

Yes, they do. And I think, to some extent, we're all end users of digital services and products. So I don't think this research will be extremely shocking to anybody. Because I know when I look at these numbers, I'm like, "Yeah, I've done that before, multiple times." So we just ran research with over 1,000 online consumers in the United States. And what we found was 84% of consumers experience password fatigue from having to set up an account in the first place. 

So that is your first interaction with a digital service, and 84% of your consumers are tired of setting the password, to begin with. And when it comes to online account registration and login, there's different steps to it, right? There's password requirements, there is security questions, there's captures, there's multi-factor. The most annoying thing for customers is password requirements. 

So that is the length of your password being over six digits long or, sorry, six...we're going to have to deal with this. It's not digit, what's the term I'm looking for? 

Tom

Characters? 

Jing

Characters, thank you. So passwords having specific requirements, including length, which is the number of characters, or sometimes as a method of breach prevention, they require special characters like an @, a $, %, whatever it is. And occasionally services will run breach protection or fraud assessment on your password, so if your password is in a database of previously breached passwords, you actually can't use that. 

And that is really frustrating for consumers and it is a top concern. The second one being forgetting passwords. Security questions I think we're at 17%, CAPTCHA was at 15. So all those things make up a lot of friction for the user. And it turns out 40% of our respondents said that they stopped using a service because they just forgot the password. 

You know, we just give up, we can't do this anymore, enough is enough. So people, companies are definitely losing customers due to authentication friction. Specifically in e-commerce, a lot of times you have the option to check out as a guest without creating an account at all, and it turns out 58% of consumers prefer to do that because the registration process is a hassle. 

And I think those are the highlights of our research in terms of consumer sentiment. As you mentioned, it's generally a lot of frustration because any friction presented to them is going to cause a drop-off at these critical steps. 

Tom

Jing, I have one more question for you and then I'm going to bring Jamie into the conversation after. 

Jing

Yeah, sure. 

Tom

When it comes to solutions, what's available for companies today and how do they compare to one another? 

Jing

Yeah, yeah, that's a good question. Because there's a lot of options, even if username and password is kind of the default in the world today. So if you wanted to move beyond username and password, one really popular option is social logins. So that is log in with Facebook, log in with Apple, log in Twitter, GitHub, all of these social platforms. Another one is using one-time codes, push notifications, or out-of-band calls. 

And what that does is you hit your login page, and then it says, "Hey, you don't have to enter a password. Please go check your phone for a code or tap on it to push notification or answer your call." And of course, the third option is passwordless. And passwordless sometimes is not created equal, because certain passwordless solutions do not actually remove the password from your database. 

And I realize I just gave a very broad overview of all of them, right? Username, password, social logins, one-time codes, push notifications and passwordless solutions. When we consider all of these solutions, and how they stack up against each other, most of them leave the password in place. So sometimes what they do is, even with face ID, is you enter your face ID, but your password still exists in the database in the back, you just don't have to engage with it as an end-user. 

The issue with that is, one, your database is prone to breaches because a password exists, passwords are valuable for attackers and, two, the password is still used for recovery purposes. So you're actually not fully protecting the account against account takeover, phishing, credential stuffing, brute force attacks. So there's a lot of security vulnerabilities with not fully removing the password. 

And the second thing is there's shortcomings in user experience. So with social logins, sometimes I forget my password to my Facebook account, which I haven't used in a few years. And with one-time codes and push notifications, I have to have my phone next to me at all times. Or if it's in the next room, I have to just kind of go on a scavenger hunt for my second device, and that actually is not an ideal user experience. 

And everything that I just said about that applies for certain passwordless solutions, whether it's biometric or they're leveraging one-time codes. When we say passwordless, right? We mean passwordless removes the password both from the user experience and the database, because that protects your customers from account takeover fraud due to credential attacks and it doesn't require the second device. 

I love my phone, I do keep it by me, but sometimes it's in another room, sometimes it's charging, and I don't have access to it. And I really don't want to go fish for it when I have to authenticate. 

Tom

Well said. Jamie, I want to bring you into the conversation now and talk about multi-factor authentication. By definition, multi-factor is any method that requires more than one factor. Are there differences between how MFA is implemented, and why does it matter? 

Jamie

Yeah, so maybe let me start with implementing MFA. There's this big question of really do you implement MFA as a mandatory step? So when all users register that they have to enroll in an MFA factor, as well as a first factor, or do they leave it optional to the end-users? 

When you're in a workforce scenario versus your consumers, you know, your employees of your organization, are forced to do whatever the policy may be. So, you know, being able to set a password and then having to enroll in maybe one or two multi-factor enrollments is mandatory. On the consumer side, you know, there's this whole concern really around adding too much friction into the journey, but also trying to protect your own user accounts. 

And I think that's one of the biggest conundrums that organizations struggle with is, well, do we want to enforce MFA to protect their account or do we just want to give them the option so that they can, you know, further protect their account if they want to? And ultimately, what we see is we see very, very low adoption rates of your traditional MFA. 

Because users, unfortunately, tend to want the kind of the path of least resistance and don't want to add that friction into their experience. So I think when we look at that, you know, organizations really need to consider kind of the value attached to their account, to their users' accounts, and understand whether really they should be enforcing this, or whether they should just give the users at least the option to make their account more secure. 

Tom

Jamie, there's been increasing interest in passwordless authentication, but existing solutions can look very similar on the surface when evaluating passwordless solutions, even starting with the definition of passwordless company to company. What are key characteristics you want to look for? 

Jamie

So yeah. The first part there in terms of passwordless, what we're really saying with passwordless is not necessarily just the password, it's effectively what we refer to as shared secrets. So it's something that the user knows, it's a knowledge-based factor. So it could be a password that they know, it could also be PII data. So it's data they know about themselves, such as their date of birth, where they were born, you know, all those questions you sometimes get asked which cause a lot of frustration. 

You know, what's your favorite food? Those kinds of things. They are effectively stored in a centralized server somewhere, you know, a database, which as Jing mentioned earlier, is vulnerable to data breaches. And so, really, when we talk about passwordless, what we actually mean is that there's no shared secrets stored in any centralized database. 

And then, yeah, absolutely, we start looking at different passwordless technologies and how you can evaluate these, and what are some of the key characteristics to look for. Well, ultimately, you want ones that are fundamentally secure by design. And what I mean by that is they're not vulnerable to other attacks. 

A lot of the misconception in identity and security is that, you know, MFA or passwordless, I can add these options on, so you almost layer security. But actually, what you're not doing, is you're not actually improving the security because a lot of these factors are vulnerable to different types of attacks. 

So we look at things like vulnerable to man-in-the-middle attacks and sending one-time codes via out-of-band methods, so SMS and emails. You know, SMS is vulnerable to things like sim swapping, sending OTPs to emails. Again, email accounts have vulnerability to account takeover, so password-based attacks as well. Because when you send things to an email address, it's only as secure as what the actual email account offers for security. 

The other key thing to look at is, yes, solutions and Jing's already mentioned this, solutions where you can completely eliminate that password. So a lot of them kind of layer on top, whereas we're really wanting to see where the passwordless solution effectively allows you to not have any shared secrets at all. And a lot of the problems that organizations struggle with there is things like recovery. 

Well, if I don't have any shared secrets, then how do I recover the user? And that's something that takes a little bit of a different mindset, in terms of how that recovery process can take place, but absolutely possible, it's just a shift in thinking.

I was going to say so that the last one there is probably, again, it comes down to friction. You want ones that lower the level of friction. So typically, a lot of the solutions out there require a second device. So you have to receive a code on your SMS, you have to pick up your phone to open an authenticator app, maybe you're sent a push notification. And then you get into things like connectivity issues, where maybe there's a problem with a push notification, which again, just leads to an increase in friction, and frustration from the end-user. 

And the other thing there as well is cross-platform support. So you know what works for a laptop, or a desktop device, might not also work for authenticating from a mobile device or an iPad, for example. So it's really important to make sure that whatever solution they're choosing, or whatever method of passwordless they're choosing, works well cross platform, and is not going to impede a user when they're using a particular device. 

Tom

Follow up on something you said. Once the password is removed, what options do companies have in terms of access control at their disposal? 

Jamie

Yeah, I mean, it's actually, you know, if we get to the point where organizations can remove the password, all of the things we've talked about so far kind of disappear, the vulnerability of the password. But it's probably not just solved at that point. I think a huge part of that, you know, improving security is removing it, but organizations do need to look at other mechanisms for how they can then go about further levels of access control. 

And we kind of see this in a couple of different terms. You know, we have workforce terms such as Carter and Zero Trust, and it's really applying them or the core principles to CIAM. And what that really means is looking at risk signals. 

So for every transaction, you know, when a user registers, they recover, they authenticate, there's always what we call signals associated with that. So it could be, you know, what is the IP address of the user, and what is the, obviously, the data related to that IP address. So maybe their geolocation, for example. Also leverage things like device security posture. 

Is the device jailbroken? You know, have we seen this device before? Those kinds of mechanisms. And that allows you then to put extra controls in place so that only certain transactions or certain authorizations can be granted based on almost like that users repeat behavior. So when you see something out of character, or you've not seen before, what we call the policy engine, for example, could put some extra friction in place, or it could even limit what the user could do in that particular session. 

Tom

- Very good. Well, I want to take some questions from our audience now. We've already had some submitted, but a reminder to attendees, if you have questions for Jamie, for Jing, send them in now. We won't get to every question, but those that we don't answer in this session we'll be sure to get responses back to you directly via email. So, Jing, Jamie, I get to bring you together on the same stage right now for these questions. First question I have for you, why is passwordless more secure than password-based authentication? 

Jamie

Yeah, great question. So, I think, you know, I'm probably going to cover a few things that I've already said here before, but effectively, you know, as we mentioned, one of the biggest problems with having a password stored in a database is you've got two kind of directions of data breaches really. You've got what we call kind of the front door, and then kind of the back door break-in. 

So you've got hackers that could, you know, basically, expose a breach via an insecure database. It sounds pretty crazy that organizations don't properly protect their database, but it's been well known in the industry to see some really high profile companies that have, you know, left an S3 bucket as public, or they've just failed to protect their security, basically, their infrastructure. 

The kind of the front door mechanism is things like phishing attacks. You know, they're the biggest problems that kind of direct to basically these breach password databases where users are tricked into thinking they've received an email or an SMS, phishing or smishing email or SMS. And it's usually sent with some form of urgency. 

So the user's mindset completely switches and says, "Oh, wow, I really need to deal with that now." And they take the normal kind of the way they would look at an email, the way they might have not noticed that, you know, there's a typo, or the domain that the email has been sent from is incorrect, or the website URL is also incorrect. 

And they, unfortunately, go to login via, you know, a fake page, and that's how they then end up leaking their password. And so, when we do that kind of shift to passwordless, all of a sudden if a user knows that they don't use a password for that site, well, then that's a different type of mindset switch. Because if the user was to try and be phished, they click the link, they go to enter the password, and hopefully, it would switch quicker that they don't use a password for this account anymore, they use passwordless. 

So, not only do you kind of reduce the landscape of, you know, phishing from being available for that particular service, but you're also changing the mindset of the user. And I'd say, for me, that's the prime reason why passwordless is more secure than passwords. 

Jing

Yeah, 1,000%. I also think, you know, what doesn't exist cannot be attacked, right? There's no password so, suddenly, all of these vectors of attack is no longer available for bad actors, phishing, smishing, credential stuffing, brute force, you can't purchase a password off the dark web and attempt to credential stuff. 

All those options are off the table. 

Jamie

Yeah, that's a really good point, actually, Jing. One of the things that just comes to mind again, is, you know, users and consumer behavior. You know, if they are using passwords, they're typically weak passwords, and in nearly all cases, they reuse across multiple sites. So you've now got, yeah, 100 of just those perfect conditions for credential stuffing attacks and dictionary-based attacks against those different services. 

So yeah, great point. 

Tom 

This question I have for the two of you. Do we need specialized development expertise to get started with passwordless authentication? 

Jamie

Yeah. I'd say in most cases, the answer is no. You know, 99%, I think, it's fair to say, of passwordless solutions out on the market, whether open source or whether via a vendor, are built using industry standards. And I say industry standard protocols. 

So in the identity world, there are protocols called OpenID Connect, OAuth, OAuth 2.0, SAML, and it's a way to integrate with various different solutions, authentication methods, via standards, so a standard way. And that allows developers to become very familiar with these types of protocols and libraries, in their kind of chosen technology stack, I suppose is the best way to say that. 

So the answer is that when developers, typically developers are the implementers or the testers of these solutions because it involves sometimes modifying the code of the application to integrate, it typically involves them becoming very familiar with what they do with one solution, and then they may look at two or three other solutions, the process should be very similar for them. 

So when they switch between integrating the different solutions, it should all of a sudden be a very familiar experience. And therefore, yeah, it doesn't require a huge amount of expertise. The other thing I'd say as well is that, you know, well-documented solutions exist out there. So there shouldn't be the need to go and do a ton of research. 

You should be able to find a handful of solutions that you want to test and they should be well documented. 

Tom

Jing, anything you'd like to add to that? 

Jing

All good. I am not as technical as Jamie is, but yes, I'm aware that standard space is best practice, and solutions with robust documentation makes it very easy for development teams to get started with passwordless. 

Tom

We've been talking about friction, we often do. It's something that we need to avoid at all costs. But, does the ideal state of customer authentication revolve around frictionless security, or are there other considerations we need to take into account as well? 

Jing

I really like this question. I think friction is interesting because you're right, right? We talk about it as if it's the boogeyman, and we have to just avoid it, and lower it at all costs. But I think really smart product and security teams can actually leverage friction as a way to ensure the security of an authentication. 

So what I mean by that is, of course, when you want your customers to register and login, you want this path to be smooth without hurdles of passwords, one-time codes or any added steps for the user. But, if they're attempting to do something a little riskier, for instance, I want to transfer a certain amount out of a bank account, or I'm trying to check my medical records or a lab result, or I am usually based in New York but suddenly I'm authenticating from somewhere I've never been, all those things are considered risk signals, right? 

Because they're not standard within my common pattern of behavior or engagement with an application. At that point, it might make sense to introduce a little bit of friction into the user experience just to say, "Hey, are you sure you're trying to do this? Is this you? Let me increase the assurance of this authentication event." And in that case, friction actually serves as a way to protect your customer's account, but friction has to be leveraged and reduced for most steps, but for certain situations where risk might justify a little bit of friction to be added to the experience for security sake, it might make sense. 

And there's different ways of doing that, right? You don't have to rely on a one-time code sent to a phone, you can just do a step-up biometric prompt that says, "Hey, can you please scan your fingerprint or give me your face again, so I can make sure that there's a real person that it matches the account?" 

So in those instances, it might make sense. Of course, frictionless by default, friction when necessary, I think is probably a more sophisticated way of approaching customer authentication. 

Tom

Jamie, anything you want to add to that? 

Jamie

I think Jing has covered all of it. To be honest, I think the biggest area of that, Jing's covered. I'd say the other thing is consumer behavior, where... Consumer behavior, is that the right term? Consumer perception. So we're kind of moving from however many years, you know, I think 30 years now of users being, you know, familiar with the experience of typing in a password, and then in the last 10 familiar with potentially, you know, going into an authenticator app, copying a code, or receiving a code via SMS. 

And then all of a sudden moving them to a passwordless world, where maybe, actually, they don't need to do anything. Because if they pick the right solution, it should be that seamless. And so you kind of have to get this thing about, you know, over the next however many years trying to at least present something to the user, so that they kind of have an idea of what's going on. 

Which, by default, adds friction. But, you know, it's trying to kind of combat that experience that they're familiar with, just to make them understand that it is still a secure mechanism of authentication. 

Tom

Very good. Well, Jamie, Jing, that brings us to the end of our session today. Thank you so much for taking time to answer my questions, as well as the questions from our audience. You've given us some great insight. Thank you very much. 

Get started with Device360 today
Popular blogs
How to Defend Against Rockstar 2FA Bypass Attacks Targeting Microsoft and Google
Learn more →
Top 10 Takeaways from BeyondCon 2024
Learn more →
An Avalanche of News About Snowflake Security
Learn more →

What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right

Download

Listen to the following security and product experts share their insights in the webinar:

  • Tom Field, Senior Vice President of Editorial with Information Security Media Group
  • Jing Gu, Senior Product Marketing Manager with Beyond Identity
  • Jamie Hughes, Product Manager with Beyond Identity. 

Transcript

Tom

Hi there. I'm Tom Field, Senior Vice President of Editorial with Information Security Media Group. Very pleased to welcome you to today's webinar, which is entitled "What Brands Get Wrong About Customer Authentication." Got two presenters for you today. They're Jing Gu, Senior Product Marketing Manager with Beyond Identity, and she's joined by Jamie Hughes, Product Manager with Beyond Identity. 

Now, before I bring Jing and Jamie onto the camera here, let me give you a little bit of background on what we're going to talk about today. Customer authentication is a critical component of almost every application that exists because it serves as a product gateway, impacting 100% of customers. While it's a standard feature, it's not easy to get right, and the stakes for getting it right are higher than ever. 

Forty-six percent of customers abandon a transaction because of authentication and account takeover fraud increased by a whopping 292% in 2020. So join us as customer authentication experts shed light on the latest findings from research and customer authentication, discuss some common misconceptions, and present effective solutions to significantly increased security without increasing friction. 

A little bit of background on my organization, Information Security Media Group. We're a global education and intelligence firm, we're based in Princeton, New Jersey. You might know us by one of our 34 media sites. These include BankInfoSecurity, HealthcareInfoSecurity, and DataBreachToday. In all, we reach an audience of 950,000 security leaders around the world, and we give them a daily diet of news, analysis, research, events, and educational programs just like this one. 

A few notes of housekeeping, if you have any questions for Jing or for Jamie during the course of this session, you can send them in anytime. Might not be able to get to everyone but, those questions that we can answer today, we will get responses back to you via email. If you should encounter any technical issues while viewing today's webinar, please take down the email address on your screen. If you write to webinars@ismg.io, we do have technical support staff standing by to help. 

Also do need to state today's webinar is copyrighted material. It's meant for today's session and individual study purposes only. If you'd like to use any of the information that's presented today, or if you're looking for customized training materials, please contact us. So I'd like to introduce our sponsor today, Beyond Identity. 

Headquartered in New York City, Beyond Identity was founded by industry legends Jim Clark and Tom Jermoluk to eliminate passwords and radically change the way that the world logs in, without requiring organizations to radically change the technology stack or processes. Funding by leading investors include Koch Disruptive Technologies and New Enterprise Associates. 

Beyond Identity's mission is to empower the next generation of secure digital business by replacing passwords with fundamentally secure X.509-based certificates. This patent-pending approach creates an extended Chain of Trust that includes user and device identity in a real-time snapshot of the device's security posture for adaptive risk-based authentication and authorization. 

Beyond Identity's cloud-native solution enables customers to increase business velocity, implement new business models, reduce operating costs, and achieve complete passwordless identity management. To learn more, please visit beyondidentity.com. And please, let's meet our speakers today. 

Jing Gu leads product marketing for Beyond Identity's customer authentication solution, responsible for driving its awareness, adoption, and growth, with an emphasis on enabling a robust developer community. Prior to Beyond Identity, she formed and led the product marketing function at Shutterstock, focused on delivering developer tools and integration products. 

When not evangelizing frictionless authentication and secure passwordless authentication, she enjoys exploring New York City, hiking, and reading. Jamie Hughes has spent the past five years for early-stage identity and Access Management companies helping to drive success in the EMEA region. His Software/DevOps Engineering background gives him the ability to advise and enable clients on all things identity with a strong focus on customer or consumer identity management. He's Product Manager today with Beyond Identity. With that, let me bring aboard Jing and Jamie. Folks, let's have a conversation about identity. Let's start here. 

Jing, set the scene, what's happening in the world today that makes it a business imperative to get customer authentication absolutely right out of the gate? 

Jing

Yeah. For sure. So customer authentication drives revenue, ultimately, right? It's not just about risk mitigation, it's not just about fraud prevention. But authentication, as you mentioned in your intro, touches 100% of your acquired customers. And guess what? Acquiring customers is really difficult, keeping them around is really difficult, and you don't want people to hit a login page or registration just to drop off. 

So there's a few ways our customer authentication drives revenue. The first is conversions at registration, login, and recovery. All those are critical steps in the customer journey, and any friction in those steps causes customers to leave your application, and sometimes they don't come back. 

And the second thing is customers nowadays are more skeptical than ever. And when they hear of a breach, or a fraud, or if that happens to them, they're not going to use your service again. Actually, according to research, 68% of consumers have stopped using our service because of a breach, even if the breach didn't happen to them directly. 

So it's about long-term trust and reputation of your business. And lastly, customer authentication sometimes, you know, people have authentication built on Legacy OAuth infrastructure, but in today's world where everyone is transacting and interacting online, digital transformation is extremely critical. And organizations with higher digital maturity recognize a 45% higher revenue growth. 

So in these three ways customer authentication, getting it right nowadays is not a negotiable part of your business strategy. 

Tom

So, Jing, when you take a step back, customer authentication is a fairly standard feature, and yet no one's really happy about it. On the company's side, passwords are highly vulnerable to attacks and it turns out that consumers are not really satisfied with that either. What does your research say about how consumers feel about their authentication options because they feel more strongly about it than ever? 

Jing

Yes, they do. And I think, to some extent, we're all end users of digital services and products. So I don't think this research will be extremely shocking to anybody. Because I know when I look at these numbers, I'm like, "Yeah, I've done that before, multiple times." So we just ran research with over 1,000 online consumers in the United States. And what we found was 84% of consumers experience password fatigue from having to set up an account in the first place. 

So that is your first interaction with a digital service, and 84% of your consumers are tired of setting the password, to begin with. And when it comes to online account registration and login, there's different steps to it, right? There's password requirements, there is security questions, there's captures, there's multi-factor. The most annoying thing for customers is password requirements. 

So that is the length of your password being over six digits long or, sorry, six...we're going to have to deal with this. It's not digit, what's the term I'm looking for? 

Tom

Characters? 

Jing

Characters, thank you. So passwords having specific requirements, including length, which is the number of characters, or sometimes as a method of breach prevention, they require special characters like an @, a $, %, whatever it is. And occasionally services will run breach protection or fraud assessment on your password, so if your password is in a database of previously breached passwords, you actually can't use that. 

And that is really frustrating for consumers and it is a top concern. The second one being forgetting passwords. Security questions I think we're at 17%, CAPTCHA was at 15. So all those things make up a lot of friction for the user. And it turns out 40% of our respondents said that they stopped using a service because they just forgot the password. 

You know, we just give up, we can't do this anymore, enough is enough. So people, companies are definitely losing customers due to authentication friction. Specifically in e-commerce, a lot of times you have the option to check out as a guest without creating an account at all, and it turns out 58% of consumers prefer to do that because the registration process is a hassle. 

And I think those are the highlights of our research in terms of consumer sentiment. As you mentioned, it's generally a lot of frustration because any friction presented to them is going to cause a drop-off at these critical steps. 

Tom

Jing, I have one more question for you and then I'm going to bring Jamie into the conversation after. 

Jing

Yeah, sure. 

Tom

When it comes to solutions, what's available for companies today and how do they compare to one another? 

Jing

Yeah, yeah, that's a good question. Because there's a lot of options, even if username and password is kind of the default in the world today. So if you wanted to move beyond username and password, one really popular option is social logins. So that is log in with Facebook, log in with Apple, log in Twitter, GitHub, all of these social platforms. Another one is using one-time codes, push notifications, or out-of-band calls. 

And what that does is you hit your login page, and then it says, "Hey, you don't have to enter a password. Please go check your phone for a code or tap on it to push notification or answer your call." And of course, the third option is passwordless. And passwordless sometimes is not created equal, because certain passwordless solutions do not actually remove the password from your database. 

And I realize I just gave a very broad overview of all of them, right? Username, password, social logins, one-time codes, push notifications and passwordless solutions. When we consider all of these solutions, and how they stack up against each other, most of them leave the password in place. So sometimes what they do is, even with face ID, is you enter your face ID, but your password still exists in the database in the back, you just don't have to engage with it as an end-user. 

The issue with that is, one, your database is prone to breaches because a password exists, passwords are valuable for attackers and, two, the password is still used for recovery purposes. So you're actually not fully protecting the account against account takeover, phishing, credential stuffing, brute force attacks. So there's a lot of security vulnerabilities with not fully removing the password. 

And the second thing is there's shortcomings in user experience. So with social logins, sometimes I forget my password to my Facebook account, which I haven't used in a few years. And with one-time codes and push notifications, I have to have my phone next to me at all times. Or if it's in the next room, I have to just kind of go on a scavenger hunt for my second device, and that actually is not an ideal user experience. 

And everything that I just said about that applies for certain passwordless solutions, whether it's biometric or they're leveraging one-time codes. When we say passwordless, right? We mean passwordless removes the password both from the user experience and the database, because that protects your customers from account takeover fraud due to credential attacks and it doesn't require the second device. 

I love my phone, I do keep it by me, but sometimes it's in another room, sometimes it's charging, and I don't have access to it. And I really don't want to go fish for it when I have to authenticate. 

Tom

Well said. Jamie, I want to bring you into the conversation now and talk about multi-factor authentication. By definition, multi-factor is any method that requires more than one factor. Are there differences between how MFA is implemented, and why does it matter? 

Jamie

Yeah, so maybe let me start with implementing MFA. There's this big question of really do you implement MFA as a mandatory step? So when all users register that they have to enroll in an MFA factor, as well as a first factor, or do they leave it optional to the end-users? 

When you're in a workforce scenario versus your consumers, you know, your employees of your organization, are forced to do whatever the policy may be. So, you know, being able to set a password and then having to enroll in maybe one or two multi-factor enrollments is mandatory. On the consumer side, you know, there's this whole concern really around adding too much friction into the journey, but also trying to protect your own user accounts. 

And I think that's one of the biggest conundrums that organizations struggle with is, well, do we want to enforce MFA to protect their account or do we just want to give them the option so that they can, you know, further protect their account if they want to? And ultimately, what we see is we see very, very low adoption rates of your traditional MFA. 

Because users, unfortunately, tend to want the kind of the path of least resistance and don't want to add that friction into their experience. So I think when we look at that, you know, organizations really need to consider kind of the value attached to their account, to their users' accounts, and understand whether really they should be enforcing this, or whether they should just give the users at least the option to make their account more secure. 

Tom

Jamie, there's been increasing interest in passwordless authentication, but existing solutions can look very similar on the surface when evaluating passwordless solutions, even starting with the definition of passwordless company to company. What are key characteristics you want to look for? 

Jamie

So yeah. The first part there in terms of passwordless, what we're really saying with passwordless is not necessarily just the password, it's effectively what we refer to as shared secrets. So it's something that the user knows, it's a knowledge-based factor. So it could be a password that they know, it could also be PII data. So it's data they know about themselves, such as their date of birth, where they were born, you know, all those questions you sometimes get asked which cause a lot of frustration. 

You know, what's your favorite food? Those kinds of things. They are effectively stored in a centralized server somewhere, you know, a database, which as Jing mentioned earlier, is vulnerable to data breaches. And so, really, when we talk about passwordless, what we actually mean is that there's no shared secrets stored in any centralized database. 

And then, yeah, absolutely, we start looking at different passwordless technologies and how you can evaluate these, and what are some of the key characteristics to look for. Well, ultimately, you want ones that are fundamentally secure by design. And what I mean by that is they're not vulnerable to other attacks. 

A lot of the misconception in identity and security is that, you know, MFA or passwordless, I can add these options on, so you almost layer security. But actually, what you're not doing, is you're not actually improving the security because a lot of these factors are vulnerable to different types of attacks. 

So we look at things like vulnerable to man-in-the-middle attacks and sending one-time codes via out-of-band methods, so SMS and emails. You know, SMS is vulnerable to things like sim swapping, sending OTPs to emails. Again, email accounts have vulnerability to account takeover, so password-based attacks as well. Because when you send things to an email address, it's only as secure as what the actual email account offers for security. 

The other key thing to look at is, yes, solutions and Jing's already mentioned this, solutions where you can completely eliminate that password. So a lot of them kind of layer on top, whereas we're really wanting to see where the passwordless solution effectively allows you to not have any shared secrets at all. And a lot of the problems that organizations struggle with there is things like recovery. 

Well, if I don't have any shared secrets, then how do I recover the user? And that's something that takes a little bit of a different mindset, in terms of how that recovery process can take place, but absolutely possible, it's just a shift in thinking.

I was going to say so that the last one there is probably, again, it comes down to friction. You want ones that lower the level of friction. So typically, a lot of the solutions out there require a second device. So you have to receive a code on your SMS, you have to pick up your phone to open an authenticator app, maybe you're sent a push notification. And then you get into things like connectivity issues, where maybe there's a problem with a push notification, which again, just leads to an increase in friction, and frustration from the end-user. 

And the other thing there as well is cross-platform support. So you know what works for a laptop, or a desktop device, might not also work for authenticating from a mobile device or an iPad, for example. So it's really important to make sure that whatever solution they're choosing, or whatever method of passwordless they're choosing, works well cross platform, and is not going to impede a user when they're using a particular device. 

Tom

Follow up on something you said. Once the password is removed, what options do companies have in terms of access control at their disposal? 

Jamie

Yeah, I mean, it's actually, you know, if we get to the point where organizations can remove the password, all of the things we've talked about so far kind of disappear, the vulnerability of the password. But it's probably not just solved at that point. I think a huge part of that, you know, improving security is removing it, but organizations do need to look at other mechanisms for how they can then go about further levels of access control. 

And we kind of see this in a couple of different terms. You know, we have workforce terms such as Carter and Zero Trust, and it's really applying them or the core principles to CIAM. And what that really means is looking at risk signals. 

So for every transaction, you know, when a user registers, they recover, they authenticate, there's always what we call signals associated with that. So it could be, you know, what is the IP address of the user, and what is the, obviously, the data related to that IP address. So maybe their geolocation, for example. Also leverage things like device security posture. 

Is the device jailbroken? You know, have we seen this device before? Those kinds of mechanisms. And that allows you then to put extra controls in place so that only certain transactions or certain authorizations can be granted based on almost like that users repeat behavior. So when you see something out of character, or you've not seen before, what we call the policy engine, for example, could put some extra friction in place, or it could even limit what the user could do in that particular session. 

Tom

- Very good. Well, I want to take some questions from our audience now. We've already had some submitted, but a reminder to attendees, if you have questions for Jamie, for Jing, send them in now. We won't get to every question, but those that we don't answer in this session we'll be sure to get responses back to you directly via email. So, Jing, Jamie, I get to bring you together on the same stage right now for these questions. First question I have for you, why is passwordless more secure than password-based authentication? 

Jamie

Yeah, great question. So, I think, you know, I'm probably going to cover a few things that I've already said here before, but effectively, you know, as we mentioned, one of the biggest problems with having a password stored in a database is you've got two kind of directions of data breaches really. You've got what we call kind of the front door, and then kind of the back door break-in. 

So you've got hackers that could, you know, basically, expose a breach via an insecure database. It sounds pretty crazy that organizations don't properly protect their database, but it's been well known in the industry to see some really high profile companies that have, you know, left an S3 bucket as public, or they've just failed to protect their security, basically, their infrastructure. 

The kind of the front door mechanism is things like phishing attacks. You know, they're the biggest problems that kind of direct to basically these breach password databases where users are tricked into thinking they've received an email or an SMS, phishing or smishing email or SMS. And it's usually sent with some form of urgency. 

So the user's mindset completely switches and says, "Oh, wow, I really need to deal with that now." And they take the normal kind of the way they would look at an email, the way they might have not noticed that, you know, there's a typo, or the domain that the email has been sent from is incorrect, or the website URL is also incorrect. 

And they, unfortunately, go to login via, you know, a fake page, and that's how they then end up leaking their password. And so, when we do that kind of shift to passwordless, all of a sudden if a user knows that they don't use a password for that site, well, then that's a different type of mindset switch. Because if the user was to try and be phished, they click the link, they go to enter the password, and hopefully, it would switch quicker that they don't use a password for this account anymore, they use passwordless. 

So, not only do you kind of reduce the landscape of, you know, phishing from being available for that particular service, but you're also changing the mindset of the user. And I'd say, for me, that's the prime reason why passwordless is more secure than passwords. 

Jing

Yeah, 1,000%. I also think, you know, what doesn't exist cannot be attacked, right? There's no password so, suddenly, all of these vectors of attack is no longer available for bad actors, phishing, smishing, credential stuffing, brute force, you can't purchase a password off the dark web and attempt to credential stuff. 

All those options are off the table. 

Jamie

Yeah, that's a really good point, actually, Jing. One of the things that just comes to mind again, is, you know, users and consumer behavior. You know, if they are using passwords, they're typically weak passwords, and in nearly all cases, they reuse across multiple sites. So you've now got, yeah, 100 of just those perfect conditions for credential stuffing attacks and dictionary-based attacks against those different services. 

So yeah, great point. 

Tom 

This question I have for the two of you. Do we need specialized development expertise to get started with passwordless authentication? 

Jamie

Yeah. I'd say in most cases, the answer is no. You know, 99%, I think, it's fair to say, of passwordless solutions out on the market, whether open source or whether via a vendor, are built using industry standards. And I say industry standard protocols. 

So in the identity world, there are protocols called OpenID Connect, OAuth, OAuth 2.0, SAML, and it's a way to integrate with various different solutions, authentication methods, via standards, so a standard way. And that allows developers to become very familiar with these types of protocols and libraries, in their kind of chosen technology stack, I suppose is the best way to say that. 

So the answer is that when developers, typically developers are the implementers or the testers of these solutions because it involves sometimes modifying the code of the application to integrate, it typically involves them becoming very familiar with what they do with one solution, and then they may look at two or three other solutions, the process should be very similar for them. 

So when they switch between integrating the different solutions, it should all of a sudden be a very familiar experience. And therefore, yeah, it doesn't require a huge amount of expertise. The other thing I'd say as well is that, you know, well-documented solutions exist out there. So there shouldn't be the need to go and do a ton of research. 

You should be able to find a handful of solutions that you want to test and they should be well documented. 

Tom

Jing, anything you'd like to add to that? 

Jing

All good. I am not as technical as Jamie is, but yes, I'm aware that standard space is best practice, and solutions with robust documentation makes it very easy for development teams to get started with passwordless. 

Tom

We've been talking about friction, we often do. It's something that we need to avoid at all costs. But, does the ideal state of customer authentication revolve around frictionless security, or are there other considerations we need to take into account as well? 

Jing

I really like this question. I think friction is interesting because you're right, right? We talk about it as if it's the boogeyman, and we have to just avoid it, and lower it at all costs. But I think really smart product and security teams can actually leverage friction as a way to ensure the security of an authentication. 

So what I mean by that is, of course, when you want your customers to register and login, you want this path to be smooth without hurdles of passwords, one-time codes or any added steps for the user. But, if they're attempting to do something a little riskier, for instance, I want to transfer a certain amount out of a bank account, or I'm trying to check my medical records or a lab result, or I am usually based in New York but suddenly I'm authenticating from somewhere I've never been, all those things are considered risk signals, right? 

Because they're not standard within my common pattern of behavior or engagement with an application. At that point, it might make sense to introduce a little bit of friction into the user experience just to say, "Hey, are you sure you're trying to do this? Is this you? Let me increase the assurance of this authentication event." And in that case, friction actually serves as a way to protect your customer's account, but friction has to be leveraged and reduced for most steps, but for certain situations where risk might justify a little bit of friction to be added to the experience for security sake, it might make sense. 

And there's different ways of doing that, right? You don't have to rely on a one-time code sent to a phone, you can just do a step-up biometric prompt that says, "Hey, can you please scan your fingerprint or give me your face again, so I can make sure that there's a real person that it matches the account?" 

So in those instances, it might make sense. Of course, frictionless by default, friction when necessary, I think is probably a more sophisticated way of approaching customer authentication. 

Tom

Jamie, anything you want to add to that? 

Jamie

I think Jing has covered all of it. To be honest, I think the biggest area of that, Jing's covered. I'd say the other thing is consumer behavior, where... Consumer behavior, is that the right term? Consumer perception. So we're kind of moving from however many years, you know, I think 30 years now of users being, you know, familiar with the experience of typing in a password, and then in the last 10 familiar with potentially, you know, going into an authenticator app, copying a code, or receiving a code via SMS. 

And then all of a sudden moving them to a passwordless world, where maybe, actually, they don't need to do anything. Because if they pick the right solution, it should be that seamless. And so you kind of have to get this thing about, you know, over the next however many years trying to at least present something to the user, so that they kind of have an idea of what's going on. 

Which, by default, adds friction. But, you know, it's trying to kind of combat that experience that they're familiar with, just to make them understand that it is still a secure mechanism of authentication. 

Tom

Very good. Well, Jamie, Jing, that brings us to the end of our session today. Thank you so much for taking time to answer my questions, as well as the questions from our audience. You've given us some great insight. Thank you very much. 

What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Listen to the following security and product experts share their insights in the webinar:

  • Tom Field, Senior Vice President of Editorial with Information Security Media Group
  • Jing Gu, Senior Product Marketing Manager with Beyond Identity
  • Jamie Hughes, Product Manager with Beyond Identity. 

Transcript

Tom

Hi there. I'm Tom Field, Senior Vice President of Editorial with Information Security Media Group. Very pleased to welcome you to today's webinar, which is entitled "What Brands Get Wrong About Customer Authentication." Got two presenters for you today. They're Jing Gu, Senior Product Marketing Manager with Beyond Identity, and she's joined by Jamie Hughes, Product Manager with Beyond Identity. 

Now, before I bring Jing and Jamie onto the camera here, let me give you a little bit of background on what we're going to talk about today. Customer authentication is a critical component of almost every application that exists because it serves as a product gateway, impacting 100% of customers. While it's a standard feature, it's not easy to get right, and the stakes for getting it right are higher than ever. 

Forty-six percent of customers abandon a transaction because of authentication and account takeover fraud increased by a whopping 292% in 2020. So join us as customer authentication experts shed light on the latest findings from research and customer authentication, discuss some common misconceptions, and present effective solutions to significantly increased security without increasing friction. 

A little bit of background on my organization, Information Security Media Group. We're a global education and intelligence firm, we're based in Princeton, New Jersey. You might know us by one of our 34 media sites. These include BankInfoSecurity, HealthcareInfoSecurity, and DataBreachToday. In all, we reach an audience of 950,000 security leaders around the world, and we give them a daily diet of news, analysis, research, events, and educational programs just like this one. 

A few notes of housekeeping, if you have any questions for Jing or for Jamie during the course of this session, you can send them in anytime. Might not be able to get to everyone but, those questions that we can answer today, we will get responses back to you via email. If you should encounter any technical issues while viewing today's webinar, please take down the email address on your screen. If you write to webinars@ismg.io, we do have technical support staff standing by to help. 

Also do need to state today's webinar is copyrighted material. It's meant for today's session and individual study purposes only. If you'd like to use any of the information that's presented today, or if you're looking for customized training materials, please contact us. So I'd like to introduce our sponsor today, Beyond Identity. 

Headquartered in New York City, Beyond Identity was founded by industry legends Jim Clark and Tom Jermoluk to eliminate passwords and radically change the way that the world logs in, without requiring organizations to radically change the technology stack or processes. Funding by leading investors include Koch Disruptive Technologies and New Enterprise Associates. 

Beyond Identity's mission is to empower the next generation of secure digital business by replacing passwords with fundamentally secure X.509-based certificates. This patent-pending approach creates an extended Chain of Trust that includes user and device identity in a real-time snapshot of the device's security posture for adaptive risk-based authentication and authorization. 

Beyond Identity's cloud-native solution enables customers to increase business velocity, implement new business models, reduce operating costs, and achieve complete passwordless identity management. To learn more, please visit beyondidentity.com. And please, let's meet our speakers today. 

Jing Gu leads product marketing for Beyond Identity's customer authentication solution, responsible for driving its awareness, adoption, and growth, with an emphasis on enabling a robust developer community. Prior to Beyond Identity, she formed and led the product marketing function at Shutterstock, focused on delivering developer tools and integration products. 

When not evangelizing frictionless authentication and secure passwordless authentication, she enjoys exploring New York City, hiking, and reading. Jamie Hughes has spent the past five years for early-stage identity and Access Management companies helping to drive success in the EMEA region. His Software/DevOps Engineering background gives him the ability to advise and enable clients on all things identity with a strong focus on customer or consumer identity management. He's Product Manager today with Beyond Identity. With that, let me bring aboard Jing and Jamie. Folks, let's have a conversation about identity. Let's start here. 

Jing, set the scene, what's happening in the world today that makes it a business imperative to get customer authentication absolutely right out of the gate? 

Jing

Yeah. For sure. So customer authentication drives revenue, ultimately, right? It's not just about risk mitigation, it's not just about fraud prevention. But authentication, as you mentioned in your intro, touches 100% of your acquired customers. And guess what? Acquiring customers is really difficult, keeping them around is really difficult, and you don't want people to hit a login page or registration just to drop off. 

So there's a few ways our customer authentication drives revenue. The first is conversions at registration, login, and recovery. All those are critical steps in the customer journey, and any friction in those steps causes customers to leave your application, and sometimes they don't come back. 

And the second thing is customers nowadays are more skeptical than ever. And when they hear of a breach, or a fraud, or if that happens to them, they're not going to use your service again. Actually, according to research, 68% of consumers have stopped using our service because of a breach, even if the breach didn't happen to them directly. 

So it's about long-term trust and reputation of your business. And lastly, customer authentication sometimes, you know, people have authentication built on Legacy OAuth infrastructure, but in today's world where everyone is transacting and interacting online, digital transformation is extremely critical. And organizations with higher digital maturity recognize a 45% higher revenue growth. 

So in these three ways customer authentication, getting it right nowadays is not a negotiable part of your business strategy. 

Tom

So, Jing, when you take a step back, customer authentication is a fairly standard feature, and yet no one's really happy about it. On the company's side, passwords are highly vulnerable to attacks and it turns out that consumers are not really satisfied with that either. What does your research say about how consumers feel about their authentication options because they feel more strongly about it than ever? 

Jing

Yes, they do. And I think, to some extent, we're all end users of digital services and products. So I don't think this research will be extremely shocking to anybody. Because I know when I look at these numbers, I'm like, "Yeah, I've done that before, multiple times." So we just ran research with over 1,000 online consumers in the United States. And what we found was 84% of consumers experience password fatigue from having to set up an account in the first place. 

So that is your first interaction with a digital service, and 84% of your consumers are tired of setting the password, to begin with. And when it comes to online account registration and login, there's different steps to it, right? There's password requirements, there is security questions, there's captures, there's multi-factor. The most annoying thing for customers is password requirements. 

So that is the length of your password being over six digits long or, sorry, six...we're going to have to deal with this. It's not digit, what's the term I'm looking for? 

Tom

Characters? 

Jing

Characters, thank you. So passwords having specific requirements, including length, which is the number of characters, or sometimes as a method of breach prevention, they require special characters like an @, a $, %, whatever it is. And occasionally services will run breach protection or fraud assessment on your password, so if your password is in a database of previously breached passwords, you actually can't use that. 

And that is really frustrating for consumers and it is a top concern. The second one being forgetting passwords. Security questions I think we're at 17%, CAPTCHA was at 15. So all those things make up a lot of friction for the user. And it turns out 40% of our respondents said that they stopped using a service because they just forgot the password. 

You know, we just give up, we can't do this anymore, enough is enough. So people, companies are definitely losing customers due to authentication friction. Specifically in e-commerce, a lot of times you have the option to check out as a guest without creating an account at all, and it turns out 58% of consumers prefer to do that because the registration process is a hassle. 

And I think those are the highlights of our research in terms of consumer sentiment. As you mentioned, it's generally a lot of frustration because any friction presented to them is going to cause a drop-off at these critical steps. 

Tom

Jing, I have one more question for you and then I'm going to bring Jamie into the conversation after. 

Jing

Yeah, sure. 

Tom

When it comes to solutions, what's available for companies today and how do they compare to one another? 

Jing

Yeah, yeah, that's a good question. Because there's a lot of options, even if username and password is kind of the default in the world today. So if you wanted to move beyond username and password, one really popular option is social logins. So that is log in with Facebook, log in with Apple, log in Twitter, GitHub, all of these social platforms. Another one is using one-time codes, push notifications, or out-of-band calls. 

And what that does is you hit your login page, and then it says, "Hey, you don't have to enter a password. Please go check your phone for a code or tap on it to push notification or answer your call." And of course, the third option is passwordless. And passwordless sometimes is not created equal, because certain passwordless solutions do not actually remove the password from your database. 

And I realize I just gave a very broad overview of all of them, right? Username, password, social logins, one-time codes, push notifications and passwordless solutions. When we consider all of these solutions, and how they stack up against each other, most of them leave the password in place. So sometimes what they do is, even with face ID, is you enter your face ID, but your password still exists in the database in the back, you just don't have to engage with it as an end-user. 

The issue with that is, one, your database is prone to breaches because a password exists, passwords are valuable for attackers and, two, the password is still used for recovery purposes. So you're actually not fully protecting the account against account takeover, phishing, credential stuffing, brute force attacks. So there's a lot of security vulnerabilities with not fully removing the password. 

And the second thing is there's shortcomings in user experience. So with social logins, sometimes I forget my password to my Facebook account, which I haven't used in a few years. And with one-time codes and push notifications, I have to have my phone next to me at all times. Or if it's in the next room, I have to just kind of go on a scavenger hunt for my second device, and that actually is not an ideal user experience. 

And everything that I just said about that applies for certain passwordless solutions, whether it's biometric or they're leveraging one-time codes. When we say passwordless, right? We mean passwordless removes the password both from the user experience and the database, because that protects your customers from account takeover fraud due to credential attacks and it doesn't require the second device. 

I love my phone, I do keep it by me, but sometimes it's in another room, sometimes it's charging, and I don't have access to it. And I really don't want to go fish for it when I have to authenticate. 

Tom

Well said. Jamie, I want to bring you into the conversation now and talk about multi-factor authentication. By definition, multi-factor is any method that requires more than one factor. Are there differences between how MFA is implemented, and why does it matter? 

Jamie

Yeah, so maybe let me start with implementing MFA. There's this big question of really do you implement MFA as a mandatory step? So when all users register that they have to enroll in an MFA factor, as well as a first factor, or do they leave it optional to the end-users? 

When you're in a workforce scenario versus your consumers, you know, your employees of your organization, are forced to do whatever the policy may be. So, you know, being able to set a password and then having to enroll in maybe one or two multi-factor enrollments is mandatory. On the consumer side, you know, there's this whole concern really around adding too much friction into the journey, but also trying to protect your own user accounts. 

And I think that's one of the biggest conundrums that organizations struggle with is, well, do we want to enforce MFA to protect their account or do we just want to give them the option so that they can, you know, further protect their account if they want to? And ultimately, what we see is we see very, very low adoption rates of your traditional MFA. 

Because users, unfortunately, tend to want the kind of the path of least resistance and don't want to add that friction into their experience. So I think when we look at that, you know, organizations really need to consider kind of the value attached to their account, to their users' accounts, and understand whether really they should be enforcing this, or whether they should just give the users at least the option to make their account more secure. 

Tom

Jamie, there's been increasing interest in passwordless authentication, but existing solutions can look very similar on the surface when evaluating passwordless solutions, even starting with the definition of passwordless company to company. What are key characteristics you want to look for? 

Jamie

So yeah. The first part there in terms of passwordless, what we're really saying with passwordless is not necessarily just the password, it's effectively what we refer to as shared secrets. So it's something that the user knows, it's a knowledge-based factor. So it could be a password that they know, it could also be PII data. So it's data they know about themselves, such as their date of birth, where they were born, you know, all those questions you sometimes get asked which cause a lot of frustration. 

You know, what's your favorite food? Those kinds of things. They are effectively stored in a centralized server somewhere, you know, a database, which as Jing mentioned earlier, is vulnerable to data breaches. And so, really, when we talk about passwordless, what we actually mean is that there's no shared secrets stored in any centralized database. 

And then, yeah, absolutely, we start looking at different passwordless technologies and how you can evaluate these, and what are some of the key characteristics to look for. Well, ultimately, you want ones that are fundamentally secure by design. And what I mean by that is they're not vulnerable to other attacks. 

A lot of the misconception in identity and security is that, you know, MFA or passwordless, I can add these options on, so you almost layer security. But actually, what you're not doing, is you're not actually improving the security because a lot of these factors are vulnerable to different types of attacks. 

So we look at things like vulnerable to man-in-the-middle attacks and sending one-time codes via out-of-band methods, so SMS and emails. You know, SMS is vulnerable to things like sim swapping, sending OTPs to emails. Again, email accounts have vulnerability to account takeover, so password-based attacks as well. Because when you send things to an email address, it's only as secure as what the actual email account offers for security. 

The other key thing to look at is, yes, solutions and Jing's already mentioned this, solutions where you can completely eliminate that password. So a lot of them kind of layer on top, whereas we're really wanting to see where the passwordless solution effectively allows you to not have any shared secrets at all. And a lot of the problems that organizations struggle with there is things like recovery. 

Well, if I don't have any shared secrets, then how do I recover the user? And that's something that takes a little bit of a different mindset, in terms of how that recovery process can take place, but absolutely possible, it's just a shift in thinking.

I was going to say so that the last one there is probably, again, it comes down to friction. You want ones that lower the level of friction. So typically, a lot of the solutions out there require a second device. So you have to receive a code on your SMS, you have to pick up your phone to open an authenticator app, maybe you're sent a push notification. And then you get into things like connectivity issues, where maybe there's a problem with a push notification, which again, just leads to an increase in friction, and frustration from the end-user. 

And the other thing there as well is cross-platform support. So you know what works for a laptop, or a desktop device, might not also work for authenticating from a mobile device or an iPad, for example. So it's really important to make sure that whatever solution they're choosing, or whatever method of passwordless they're choosing, works well cross platform, and is not going to impede a user when they're using a particular device. 

Tom

Follow up on something you said. Once the password is removed, what options do companies have in terms of access control at their disposal? 

Jamie

Yeah, I mean, it's actually, you know, if we get to the point where organizations can remove the password, all of the things we've talked about so far kind of disappear, the vulnerability of the password. But it's probably not just solved at that point. I think a huge part of that, you know, improving security is removing it, but organizations do need to look at other mechanisms for how they can then go about further levels of access control. 

And we kind of see this in a couple of different terms. You know, we have workforce terms such as Carter and Zero Trust, and it's really applying them or the core principles to CIAM. And what that really means is looking at risk signals. 

So for every transaction, you know, when a user registers, they recover, they authenticate, there's always what we call signals associated with that. So it could be, you know, what is the IP address of the user, and what is the, obviously, the data related to that IP address. So maybe their geolocation, for example. Also leverage things like device security posture. 

Is the device jailbroken? You know, have we seen this device before? Those kinds of mechanisms. And that allows you then to put extra controls in place so that only certain transactions or certain authorizations can be granted based on almost like that users repeat behavior. So when you see something out of character, or you've not seen before, what we call the policy engine, for example, could put some extra friction in place, or it could even limit what the user could do in that particular session. 

Tom

- Very good. Well, I want to take some questions from our audience now. We've already had some submitted, but a reminder to attendees, if you have questions for Jamie, for Jing, send them in now. We won't get to every question, but those that we don't answer in this session we'll be sure to get responses back to you directly via email. So, Jing, Jamie, I get to bring you together on the same stage right now for these questions. First question I have for you, why is passwordless more secure than password-based authentication? 

Jamie

Yeah, great question. So, I think, you know, I'm probably going to cover a few things that I've already said here before, but effectively, you know, as we mentioned, one of the biggest problems with having a password stored in a database is you've got two kind of directions of data breaches really. You've got what we call kind of the front door, and then kind of the back door break-in. 

So you've got hackers that could, you know, basically, expose a breach via an insecure database. It sounds pretty crazy that organizations don't properly protect their database, but it's been well known in the industry to see some really high profile companies that have, you know, left an S3 bucket as public, or they've just failed to protect their security, basically, their infrastructure. 

The kind of the front door mechanism is things like phishing attacks. You know, they're the biggest problems that kind of direct to basically these breach password databases where users are tricked into thinking they've received an email or an SMS, phishing or smishing email or SMS. And it's usually sent with some form of urgency. 

So the user's mindset completely switches and says, "Oh, wow, I really need to deal with that now." And they take the normal kind of the way they would look at an email, the way they might have not noticed that, you know, there's a typo, or the domain that the email has been sent from is incorrect, or the website URL is also incorrect. 

And they, unfortunately, go to login via, you know, a fake page, and that's how they then end up leaking their password. And so, when we do that kind of shift to passwordless, all of a sudden if a user knows that they don't use a password for that site, well, then that's a different type of mindset switch. Because if the user was to try and be phished, they click the link, they go to enter the password, and hopefully, it would switch quicker that they don't use a password for this account anymore, they use passwordless. 

So, not only do you kind of reduce the landscape of, you know, phishing from being available for that particular service, but you're also changing the mindset of the user. And I'd say, for me, that's the prime reason why passwordless is more secure than passwords. 

Jing

Yeah, 1,000%. I also think, you know, what doesn't exist cannot be attacked, right? There's no password so, suddenly, all of these vectors of attack is no longer available for bad actors, phishing, smishing, credential stuffing, brute force, you can't purchase a password off the dark web and attempt to credential stuff. 

All those options are off the table. 

Jamie

Yeah, that's a really good point, actually, Jing. One of the things that just comes to mind again, is, you know, users and consumer behavior. You know, if they are using passwords, they're typically weak passwords, and in nearly all cases, they reuse across multiple sites. So you've now got, yeah, 100 of just those perfect conditions for credential stuffing attacks and dictionary-based attacks against those different services. 

So yeah, great point. 

Tom 

This question I have for the two of you. Do we need specialized development expertise to get started with passwordless authentication? 

Jamie

Yeah. I'd say in most cases, the answer is no. You know, 99%, I think, it's fair to say, of passwordless solutions out on the market, whether open source or whether via a vendor, are built using industry standards. And I say industry standard protocols. 

So in the identity world, there are protocols called OpenID Connect, OAuth, OAuth 2.0, SAML, and it's a way to integrate with various different solutions, authentication methods, via standards, so a standard way. And that allows developers to become very familiar with these types of protocols and libraries, in their kind of chosen technology stack, I suppose is the best way to say that. 

So the answer is that when developers, typically developers are the implementers or the testers of these solutions because it involves sometimes modifying the code of the application to integrate, it typically involves them becoming very familiar with what they do with one solution, and then they may look at two or three other solutions, the process should be very similar for them. 

So when they switch between integrating the different solutions, it should all of a sudden be a very familiar experience. And therefore, yeah, it doesn't require a huge amount of expertise. The other thing I'd say as well is that, you know, well-documented solutions exist out there. So there shouldn't be the need to go and do a ton of research. 

You should be able to find a handful of solutions that you want to test and they should be well documented. 

Tom

Jing, anything you'd like to add to that? 

Jing

All good. I am not as technical as Jamie is, but yes, I'm aware that standard space is best practice, and solutions with robust documentation makes it very easy for development teams to get started with passwordless. 

Tom

We've been talking about friction, we often do. It's something that we need to avoid at all costs. But, does the ideal state of customer authentication revolve around frictionless security, or are there other considerations we need to take into account as well? 

Jing

I really like this question. I think friction is interesting because you're right, right? We talk about it as if it's the boogeyman, and we have to just avoid it, and lower it at all costs. But I think really smart product and security teams can actually leverage friction as a way to ensure the security of an authentication. 

So what I mean by that is, of course, when you want your customers to register and login, you want this path to be smooth without hurdles of passwords, one-time codes or any added steps for the user. But, if they're attempting to do something a little riskier, for instance, I want to transfer a certain amount out of a bank account, or I'm trying to check my medical records or a lab result, or I am usually based in New York but suddenly I'm authenticating from somewhere I've never been, all those things are considered risk signals, right? 

Because they're not standard within my common pattern of behavior or engagement with an application. At that point, it might make sense to introduce a little bit of friction into the user experience just to say, "Hey, are you sure you're trying to do this? Is this you? Let me increase the assurance of this authentication event." And in that case, friction actually serves as a way to protect your customer's account, but friction has to be leveraged and reduced for most steps, but for certain situations where risk might justify a little bit of friction to be added to the experience for security sake, it might make sense. 

And there's different ways of doing that, right? You don't have to rely on a one-time code sent to a phone, you can just do a step-up biometric prompt that says, "Hey, can you please scan your fingerprint or give me your face again, so I can make sure that there's a real person that it matches the account?" 

So in those instances, it might make sense. Of course, frictionless by default, friction when necessary, I think is probably a more sophisticated way of approaching customer authentication. 

Tom

Jamie, anything you want to add to that? 

Jamie

I think Jing has covered all of it. To be honest, I think the biggest area of that, Jing's covered. I'd say the other thing is consumer behavior, where... Consumer behavior, is that the right term? Consumer perception. So we're kind of moving from however many years, you know, I think 30 years now of users being, you know, familiar with the experience of typing in a password, and then in the last 10 familiar with potentially, you know, going into an authenticator app, copying a code, or receiving a code via SMS. 

And then all of a sudden moving them to a passwordless world, where maybe, actually, they don't need to do anything. Because if they pick the right solution, it should be that seamless. And so you kind of have to get this thing about, you know, over the next however many years trying to at least present something to the user, so that they kind of have an idea of what's going on. 

Which, by default, adds friction. But, you know, it's trying to kind of combat that experience that they're familiar with, just to make them understand that it is still a secure mechanism of authentication. 

Tom

Very good. Well, Jamie, Jing, that brings us to the end of our session today. Thank you so much for taking time to answer my questions, as well as the questions from our audience. You've given us some great insight. Thank you very much. 

What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Subscribe on SpotifySubscribe on Apple

Listen to the following security and product experts share their insights in the webinar:

  • Tom Field, Senior Vice President of Editorial with Information Security Media Group
  • Jing Gu, Senior Product Marketing Manager with Beyond Identity
  • Jamie Hughes, Product Manager with Beyond Identity. 

Transcript

Tom

Hi there. I'm Tom Field, Senior Vice President of Editorial with Information Security Media Group. Very pleased to welcome you to today's webinar, which is entitled "What Brands Get Wrong About Customer Authentication." Got two presenters for you today. They're Jing Gu, Senior Product Marketing Manager with Beyond Identity, and she's joined by Jamie Hughes, Product Manager with Beyond Identity. 

Now, before I bring Jing and Jamie onto the camera here, let me give you a little bit of background on what we're going to talk about today. Customer authentication is a critical component of almost every application that exists because it serves as a product gateway, impacting 100% of customers. While it's a standard feature, it's not easy to get right, and the stakes for getting it right are higher than ever. 

Forty-six percent of customers abandon a transaction because of authentication and account takeover fraud increased by a whopping 292% in 2020. So join us as customer authentication experts shed light on the latest findings from research and customer authentication, discuss some common misconceptions, and present effective solutions to significantly increased security without increasing friction. 

A little bit of background on my organization, Information Security Media Group. We're a global education and intelligence firm, we're based in Princeton, New Jersey. You might know us by one of our 34 media sites. These include BankInfoSecurity, HealthcareInfoSecurity, and DataBreachToday. In all, we reach an audience of 950,000 security leaders around the world, and we give them a daily diet of news, analysis, research, events, and educational programs just like this one. 

A few notes of housekeeping, if you have any questions for Jing or for Jamie during the course of this session, you can send them in anytime. Might not be able to get to everyone but, those questions that we can answer today, we will get responses back to you via email. If you should encounter any technical issues while viewing today's webinar, please take down the email address on your screen. If you write to webinars@ismg.io, we do have technical support staff standing by to help. 

Also do need to state today's webinar is copyrighted material. It's meant for today's session and individual study purposes only. If you'd like to use any of the information that's presented today, or if you're looking for customized training materials, please contact us. So I'd like to introduce our sponsor today, Beyond Identity. 

Headquartered in New York City, Beyond Identity was founded by industry legends Jim Clark and Tom Jermoluk to eliminate passwords and radically change the way that the world logs in, without requiring organizations to radically change the technology stack or processes. Funding by leading investors include Koch Disruptive Technologies and New Enterprise Associates. 

Beyond Identity's mission is to empower the next generation of secure digital business by replacing passwords with fundamentally secure X.509-based certificates. This patent-pending approach creates an extended Chain of Trust that includes user and device identity in a real-time snapshot of the device's security posture for adaptive risk-based authentication and authorization. 

Beyond Identity's cloud-native solution enables customers to increase business velocity, implement new business models, reduce operating costs, and achieve complete passwordless identity management. To learn more, please visit beyondidentity.com. And please, let's meet our speakers today. 

Jing Gu leads product marketing for Beyond Identity's customer authentication solution, responsible for driving its awareness, adoption, and growth, with an emphasis on enabling a robust developer community. Prior to Beyond Identity, she formed and led the product marketing function at Shutterstock, focused on delivering developer tools and integration products. 

When not evangelizing frictionless authentication and secure passwordless authentication, she enjoys exploring New York City, hiking, and reading. Jamie Hughes has spent the past five years for early-stage identity and Access Management companies helping to drive success in the EMEA region. His Software/DevOps Engineering background gives him the ability to advise and enable clients on all things identity with a strong focus on customer or consumer identity management. He's Product Manager today with Beyond Identity. With that, let me bring aboard Jing and Jamie. Folks, let's have a conversation about identity. Let's start here. 

Jing, set the scene, what's happening in the world today that makes it a business imperative to get customer authentication absolutely right out of the gate? 

Jing

Yeah. For sure. So customer authentication drives revenue, ultimately, right? It's not just about risk mitigation, it's not just about fraud prevention. But authentication, as you mentioned in your intro, touches 100% of your acquired customers. And guess what? Acquiring customers is really difficult, keeping them around is really difficult, and you don't want people to hit a login page or registration just to drop off. 

So there's a few ways our customer authentication drives revenue. The first is conversions at registration, login, and recovery. All those are critical steps in the customer journey, and any friction in those steps causes customers to leave your application, and sometimes they don't come back. 

And the second thing is customers nowadays are more skeptical than ever. And when they hear of a breach, or a fraud, or if that happens to them, they're not going to use your service again. Actually, according to research, 68% of consumers have stopped using our service because of a breach, even if the breach didn't happen to them directly. 

So it's about long-term trust and reputation of your business. And lastly, customer authentication sometimes, you know, people have authentication built on Legacy OAuth infrastructure, but in today's world where everyone is transacting and interacting online, digital transformation is extremely critical. And organizations with higher digital maturity recognize a 45% higher revenue growth. 

So in these three ways customer authentication, getting it right nowadays is not a negotiable part of your business strategy. 

Tom

So, Jing, when you take a step back, customer authentication is a fairly standard feature, and yet no one's really happy about it. On the company's side, passwords are highly vulnerable to attacks and it turns out that consumers are not really satisfied with that either. What does your research say about how consumers feel about their authentication options because they feel more strongly about it than ever? 

Jing

Yes, they do. And I think, to some extent, we're all end users of digital services and products. So I don't think this research will be extremely shocking to anybody. Because I know when I look at these numbers, I'm like, "Yeah, I've done that before, multiple times." So we just ran research with over 1,000 online consumers in the United States. And what we found was 84% of consumers experience password fatigue from having to set up an account in the first place. 

So that is your first interaction with a digital service, and 84% of your consumers are tired of setting the password, to begin with. And when it comes to online account registration and login, there's different steps to it, right? There's password requirements, there is security questions, there's captures, there's multi-factor. The most annoying thing for customers is password requirements. 

So that is the length of your password being over six digits long or, sorry, six...we're going to have to deal with this. It's not digit, what's the term I'm looking for? 

Tom

Characters? 

Jing

Characters, thank you. So passwords having specific requirements, including length, which is the number of characters, or sometimes as a method of breach prevention, they require special characters like an @, a $, %, whatever it is. And occasionally services will run breach protection or fraud assessment on your password, so if your password is in a database of previously breached passwords, you actually can't use that. 

And that is really frustrating for consumers and it is a top concern. The second one being forgetting passwords. Security questions I think we're at 17%, CAPTCHA was at 15. So all those things make up a lot of friction for the user. And it turns out 40% of our respondents said that they stopped using a service because they just forgot the password. 

You know, we just give up, we can't do this anymore, enough is enough. So people, companies are definitely losing customers due to authentication friction. Specifically in e-commerce, a lot of times you have the option to check out as a guest without creating an account at all, and it turns out 58% of consumers prefer to do that because the registration process is a hassle. 

And I think those are the highlights of our research in terms of consumer sentiment. As you mentioned, it's generally a lot of frustration because any friction presented to them is going to cause a drop-off at these critical steps. 

Tom

Jing, I have one more question for you and then I'm going to bring Jamie into the conversation after. 

Jing

Yeah, sure. 

Tom

When it comes to solutions, what's available for companies today and how do they compare to one another? 

Jing

Yeah, yeah, that's a good question. Because there's a lot of options, even if username and password is kind of the default in the world today. So if you wanted to move beyond username and password, one really popular option is social logins. So that is log in with Facebook, log in with Apple, log in Twitter, GitHub, all of these social platforms. Another one is using one-time codes, push notifications, or out-of-band calls. 

And what that does is you hit your login page, and then it says, "Hey, you don't have to enter a password. Please go check your phone for a code or tap on it to push notification or answer your call." And of course, the third option is passwordless. And passwordless sometimes is not created equal, because certain passwordless solutions do not actually remove the password from your database. 

And I realize I just gave a very broad overview of all of them, right? Username, password, social logins, one-time codes, push notifications and passwordless solutions. When we consider all of these solutions, and how they stack up against each other, most of them leave the password in place. So sometimes what they do is, even with face ID, is you enter your face ID, but your password still exists in the database in the back, you just don't have to engage with it as an end-user. 

The issue with that is, one, your database is prone to breaches because a password exists, passwords are valuable for attackers and, two, the password is still used for recovery purposes. So you're actually not fully protecting the account against account takeover, phishing, credential stuffing, brute force attacks. So there's a lot of security vulnerabilities with not fully removing the password. 

And the second thing is there's shortcomings in user experience. So with social logins, sometimes I forget my password to my Facebook account, which I haven't used in a few years. And with one-time codes and push notifications, I have to have my phone next to me at all times. Or if it's in the next room, I have to just kind of go on a scavenger hunt for my second device, and that actually is not an ideal user experience. 

And everything that I just said about that applies for certain passwordless solutions, whether it's biometric or they're leveraging one-time codes. When we say passwordless, right? We mean passwordless removes the password both from the user experience and the database, because that protects your customers from account takeover fraud due to credential attacks and it doesn't require the second device. 

I love my phone, I do keep it by me, but sometimes it's in another room, sometimes it's charging, and I don't have access to it. And I really don't want to go fish for it when I have to authenticate. 

Tom

Well said. Jamie, I want to bring you into the conversation now and talk about multi-factor authentication. By definition, multi-factor is any method that requires more than one factor. Are there differences between how MFA is implemented, and why does it matter? 

Jamie

Yeah, so maybe let me start with implementing MFA. There's this big question of really do you implement MFA as a mandatory step? So when all users register that they have to enroll in an MFA factor, as well as a first factor, or do they leave it optional to the end-users? 

When you're in a workforce scenario versus your consumers, you know, your employees of your organization, are forced to do whatever the policy may be. So, you know, being able to set a password and then having to enroll in maybe one or two multi-factor enrollments is mandatory. On the consumer side, you know, there's this whole concern really around adding too much friction into the journey, but also trying to protect your own user accounts. 

And I think that's one of the biggest conundrums that organizations struggle with is, well, do we want to enforce MFA to protect their account or do we just want to give them the option so that they can, you know, further protect their account if they want to? And ultimately, what we see is we see very, very low adoption rates of your traditional MFA. 

Because users, unfortunately, tend to want the kind of the path of least resistance and don't want to add that friction into their experience. So I think when we look at that, you know, organizations really need to consider kind of the value attached to their account, to their users' accounts, and understand whether really they should be enforcing this, or whether they should just give the users at least the option to make their account more secure. 

Tom

Jamie, there's been increasing interest in passwordless authentication, but existing solutions can look very similar on the surface when evaluating passwordless solutions, even starting with the definition of passwordless company to company. What are key characteristics you want to look for? 

Jamie

So yeah. The first part there in terms of passwordless, what we're really saying with passwordless is not necessarily just the password, it's effectively what we refer to as shared secrets. So it's something that the user knows, it's a knowledge-based factor. So it could be a password that they know, it could also be PII data. So it's data they know about themselves, such as their date of birth, where they were born, you know, all those questions you sometimes get asked which cause a lot of frustration. 

You know, what's your favorite food? Those kinds of things. They are effectively stored in a centralized server somewhere, you know, a database, which as Jing mentioned earlier, is vulnerable to data breaches. And so, really, when we talk about passwordless, what we actually mean is that there's no shared secrets stored in any centralized database. 

And then, yeah, absolutely, we start looking at different passwordless technologies and how you can evaluate these, and what are some of the key characteristics to look for. Well, ultimately, you want ones that are fundamentally secure by design. And what I mean by that is they're not vulnerable to other attacks. 

A lot of the misconception in identity and security is that, you know, MFA or passwordless, I can add these options on, so you almost layer security. But actually, what you're not doing, is you're not actually improving the security because a lot of these factors are vulnerable to different types of attacks. 

So we look at things like vulnerable to man-in-the-middle attacks and sending one-time codes via out-of-band methods, so SMS and emails. You know, SMS is vulnerable to things like sim swapping, sending OTPs to emails. Again, email accounts have vulnerability to account takeover, so password-based attacks as well. Because when you send things to an email address, it's only as secure as what the actual email account offers for security. 

The other key thing to look at is, yes, solutions and Jing's already mentioned this, solutions where you can completely eliminate that password. So a lot of them kind of layer on top, whereas we're really wanting to see where the passwordless solution effectively allows you to not have any shared secrets at all. And a lot of the problems that organizations struggle with there is things like recovery. 

Well, if I don't have any shared secrets, then how do I recover the user? And that's something that takes a little bit of a different mindset, in terms of how that recovery process can take place, but absolutely possible, it's just a shift in thinking.

I was going to say so that the last one there is probably, again, it comes down to friction. You want ones that lower the level of friction. So typically, a lot of the solutions out there require a second device. So you have to receive a code on your SMS, you have to pick up your phone to open an authenticator app, maybe you're sent a push notification. And then you get into things like connectivity issues, where maybe there's a problem with a push notification, which again, just leads to an increase in friction, and frustration from the end-user. 

And the other thing there as well is cross-platform support. So you know what works for a laptop, or a desktop device, might not also work for authenticating from a mobile device or an iPad, for example. So it's really important to make sure that whatever solution they're choosing, or whatever method of passwordless they're choosing, works well cross platform, and is not going to impede a user when they're using a particular device. 

Tom

Follow up on something you said. Once the password is removed, what options do companies have in terms of access control at their disposal? 

Jamie

Yeah, I mean, it's actually, you know, if we get to the point where organizations can remove the password, all of the things we've talked about so far kind of disappear, the vulnerability of the password. But it's probably not just solved at that point. I think a huge part of that, you know, improving security is removing it, but organizations do need to look at other mechanisms for how they can then go about further levels of access control. 

And we kind of see this in a couple of different terms. You know, we have workforce terms such as Carter and Zero Trust, and it's really applying them or the core principles to CIAM. And what that really means is looking at risk signals. 

So for every transaction, you know, when a user registers, they recover, they authenticate, there's always what we call signals associated with that. So it could be, you know, what is the IP address of the user, and what is the, obviously, the data related to that IP address. So maybe their geolocation, for example. Also leverage things like device security posture. 

Is the device jailbroken? You know, have we seen this device before? Those kinds of mechanisms. And that allows you then to put extra controls in place so that only certain transactions or certain authorizations can be granted based on almost like that users repeat behavior. So when you see something out of character, or you've not seen before, what we call the policy engine, for example, could put some extra friction in place, or it could even limit what the user could do in that particular session. 

Tom

- Very good. Well, I want to take some questions from our audience now. We've already had some submitted, but a reminder to attendees, if you have questions for Jamie, for Jing, send them in now. We won't get to every question, but those that we don't answer in this session we'll be sure to get responses back to you directly via email. So, Jing, Jamie, I get to bring you together on the same stage right now for these questions. First question I have for you, why is passwordless more secure than password-based authentication? 

Jamie

Yeah, great question. So, I think, you know, I'm probably going to cover a few things that I've already said here before, but effectively, you know, as we mentioned, one of the biggest problems with having a password stored in a database is you've got two kind of directions of data breaches really. You've got what we call kind of the front door, and then kind of the back door break-in. 

So you've got hackers that could, you know, basically, expose a breach via an insecure database. It sounds pretty crazy that organizations don't properly protect their database, but it's been well known in the industry to see some really high profile companies that have, you know, left an S3 bucket as public, or they've just failed to protect their security, basically, their infrastructure. 

The kind of the front door mechanism is things like phishing attacks. You know, they're the biggest problems that kind of direct to basically these breach password databases where users are tricked into thinking they've received an email or an SMS, phishing or smishing email or SMS. And it's usually sent with some form of urgency. 

So the user's mindset completely switches and says, "Oh, wow, I really need to deal with that now." And they take the normal kind of the way they would look at an email, the way they might have not noticed that, you know, there's a typo, or the domain that the email has been sent from is incorrect, or the website URL is also incorrect. 

And they, unfortunately, go to login via, you know, a fake page, and that's how they then end up leaking their password. And so, when we do that kind of shift to passwordless, all of a sudden if a user knows that they don't use a password for that site, well, then that's a different type of mindset switch. Because if the user was to try and be phished, they click the link, they go to enter the password, and hopefully, it would switch quicker that they don't use a password for this account anymore, they use passwordless. 

So, not only do you kind of reduce the landscape of, you know, phishing from being available for that particular service, but you're also changing the mindset of the user. And I'd say, for me, that's the prime reason why passwordless is more secure than passwords. 

Jing

Yeah, 1,000%. I also think, you know, what doesn't exist cannot be attacked, right? There's no password so, suddenly, all of these vectors of attack is no longer available for bad actors, phishing, smishing, credential stuffing, brute force, you can't purchase a password off the dark web and attempt to credential stuff. 

All those options are off the table. 

Jamie

Yeah, that's a really good point, actually, Jing. One of the things that just comes to mind again, is, you know, users and consumer behavior. You know, if they are using passwords, they're typically weak passwords, and in nearly all cases, they reuse across multiple sites. So you've now got, yeah, 100 of just those perfect conditions for credential stuffing attacks and dictionary-based attacks against those different services. 

So yeah, great point. 

Tom 

This question I have for the two of you. Do we need specialized development expertise to get started with passwordless authentication? 

Jamie

Yeah. I'd say in most cases, the answer is no. You know, 99%, I think, it's fair to say, of passwordless solutions out on the market, whether open source or whether via a vendor, are built using industry standards. And I say industry standard protocols. 

So in the identity world, there are protocols called OpenID Connect, OAuth, OAuth 2.0, SAML, and it's a way to integrate with various different solutions, authentication methods, via standards, so a standard way. And that allows developers to become very familiar with these types of protocols and libraries, in their kind of chosen technology stack, I suppose is the best way to say that. 

So the answer is that when developers, typically developers are the implementers or the testers of these solutions because it involves sometimes modifying the code of the application to integrate, it typically involves them becoming very familiar with what they do with one solution, and then they may look at two or three other solutions, the process should be very similar for them. 

So when they switch between integrating the different solutions, it should all of a sudden be a very familiar experience. And therefore, yeah, it doesn't require a huge amount of expertise. The other thing I'd say as well is that, you know, well-documented solutions exist out there. So there shouldn't be the need to go and do a ton of research. 

You should be able to find a handful of solutions that you want to test and they should be well documented. 

Tom

Jing, anything you'd like to add to that? 

Jing

All good. I am not as technical as Jamie is, but yes, I'm aware that standard space is best practice, and solutions with robust documentation makes it very easy for development teams to get started with passwordless. 

Tom

We've been talking about friction, we often do. It's something that we need to avoid at all costs. But, does the ideal state of customer authentication revolve around frictionless security, or are there other considerations we need to take into account as well? 

Jing

I really like this question. I think friction is interesting because you're right, right? We talk about it as if it's the boogeyman, and we have to just avoid it, and lower it at all costs. But I think really smart product and security teams can actually leverage friction as a way to ensure the security of an authentication. 

So what I mean by that is, of course, when you want your customers to register and login, you want this path to be smooth without hurdles of passwords, one-time codes or any added steps for the user. But, if they're attempting to do something a little riskier, for instance, I want to transfer a certain amount out of a bank account, or I'm trying to check my medical records or a lab result, or I am usually based in New York but suddenly I'm authenticating from somewhere I've never been, all those things are considered risk signals, right? 

Because they're not standard within my common pattern of behavior or engagement with an application. At that point, it might make sense to introduce a little bit of friction into the user experience just to say, "Hey, are you sure you're trying to do this? Is this you? Let me increase the assurance of this authentication event." And in that case, friction actually serves as a way to protect your customer's account, but friction has to be leveraged and reduced for most steps, but for certain situations where risk might justify a little bit of friction to be added to the experience for security sake, it might make sense. 

And there's different ways of doing that, right? You don't have to rely on a one-time code sent to a phone, you can just do a step-up biometric prompt that says, "Hey, can you please scan your fingerprint or give me your face again, so I can make sure that there's a real person that it matches the account?" 

So in those instances, it might make sense. Of course, frictionless by default, friction when necessary, I think is probably a more sophisticated way of approaching customer authentication. 

Tom

Jamie, anything you want to add to that? 

Jamie

I think Jing has covered all of it. To be honest, I think the biggest area of that, Jing's covered. I'd say the other thing is consumer behavior, where... Consumer behavior, is that the right term? Consumer perception. So we're kind of moving from however many years, you know, I think 30 years now of users being, you know, familiar with the experience of typing in a password, and then in the last 10 familiar with potentially, you know, going into an authenticator app, copying a code, or receiving a code via SMS. 

And then all of a sudden moving them to a passwordless world, where maybe, actually, they don't need to do anything. Because if they pick the right solution, it should be that seamless. And so you kind of have to get this thing about, you know, over the next however many years trying to at least present something to the user, so that they kind of have an idea of what's going on. 

Which, by default, adds friction. But, you know, it's trying to kind of combat that experience that they're familiar with, just to make them understand that it is still a secure mechanism of authentication. 

Tom

Very good. Well, Jamie, Jing, that brings us to the end of our session today. Thank you so much for taking time to answer my questions, as well as the questions from our audience. You've given us some great insight. Thank you very much. 

Book

What Brands Get Wrong About Customer Authentication: Why It's Imperative to Get Customer Authentication Right

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Download the book

Download the book

Download the book
suggested resources
Zero Trust
Passwordless
DevOps
CIAM
Workforce
Infographic
Secure Workforce
Thought Leadership
Product
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
PreferencesDenyAccept