[podcast] Authentication Talk with Mario from Callsign
Both Jeff and Jim have over a decade of experience in the Identity & Access Management space and guide companies on their IAM Program journey through Identropy's Advisory Services arm.
We hope you enjoy this episode and please subscribe to the podcast for updates on new episodes!
Listen Here or read the full transcript below.
*Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.
Podcast #9 Full Transcript:
Identity At The Center #9: Authentication Talk with Mario from Callsign
Jeff: Welcome to another episode of Identity at the Center. This is the official podcast of me, Jeff Steadman. Jim, I'm hoping it's the official podcast of you as well. Is that right?
Jim: It's my one and only podcast, Jeff, but I think about expanding on to other topics, we’ll see what happens.
Jeff: I'm surprised you don't do a baseball interview and something.
Jim: Nobody wants to hear me go off.
Jeff: I've heard enough it over the last few years that I'm always interested to hear what's going on, a Yankee baseball.
Jim: I watch a lot of it. So, hey, Jeff, today we're joined by Mario Dusaj. And I talk about Mario on our very first podcast. People can go back and listen. And I mistakenly said he was from Transmit Security. We later retracted that and corrected that. He's with Callsign. Oh, we're very fortunate that Mario on the call today, hey, Mario.
Mario: I'm doing great, Jim. Thanks, guys, for the opportunity to be here, really excited.
Jim: It's great. Yeah. You and I have worked together for a long time at the financial services industry and later as Identropy for several years we were sorry to see you go. But we're glad to have you back to the podcast.
Mario: Thanks. It's exciting and you know, it's a very small space. So people never really leave, you're always going to work together at some at some point in the future. And I'm happy to be working with you again.
Jim: Great. So what have you been doing at Callsign?
Mario: Callsign is Solutions architect. So basically, I'm responsible for several different things. You know, where I'm helping out on pre-sale sites.
We're doing a lot of know, kind of waving a flag about the technology, talking about what we're doing and really trying to get customers interested in. And then I'm also doing, actual architecture.
So designing systems, talking to people and showing customers this solution can fit into their environment and really bring value to them and ultimately secure their environments in a better way.
Jeff: So, Mario, if you look at the Web site, right, there's a tagline says, Real time A.I. driven identity and authentication solutions that confirm the user really is who they say they are at work and at home. What the heck does that mean?
Mario: It sounds pretty cool, doesn't it?
Jeff: It sounds like a whole bunch of stuff. And like, what is that?
Mario: So it really is a whole bunch of different things. And let's be honest with you.
And what we're really doing is we're taking the latest in machine learning and artificial intelligence and really threat indicators and where we're guiding users to the most secure and the most appropriate journey to make sure that we're letting the right people in based on all of these things that we are know that we're that we know about them. So we're looking at behavior. We're looking at things about the device. Is there possible malware device? We're looking at how they interact with the device. We're also looking at location and other things that are coming in. And, in a split second, really like fifty milliseconds, we're making accurate decisions about their authenticity and letting them into the systems easily during any additional friction where it's necessary.
Does that help?
Jeff: I think so.
So, if I've got a phone right, and I'm logging in maybe like a bank or something, that you're taking some of the characteristics of my phone, maybe some of the sensors on it to help kind of place me and making sure that it's not just my password, it's authenticating, but also getting some sort of. I would imagine it's like a risk engine behind the scenes that's providing some sort of hate. What if you're this level of risk, it's OK. Or if it's not, it's not OK, that kind of thing.
Mario: That's it. That's absolutely right. So we're looking at the way that you interact with the device. So, maybe you keep your posts so you keep your username and password on a Post-it note and somebody can get access to that.
And then, you know, typical system, so long as you're on your device, they get in. So what we're looking at is the way that somebody is interacting with the device. So it's above and beyond a knowledge base authenticator so you can have a password. We're looking at behavior. So we use employed a series of like passive authenticators to detect, riskiness and authenticity of the person on device. And if it looks like it's you, then we let them in. But if it looks like it's me trying to beat you with your username password, then we'll challenge them for face recognition or fingerprint or something different. There’s a plethora of different authenticators we can employ when it's necessary.
Jeff: Interesting. How do you tune that? Or is it going to end enrollment period? I guess how do you know this? How do you know it's me? And not just somebody picked up my phone, I guess.
Mario: Right. So first thing we have a network of models, machine learning models.
And we're not using averages, so to speak. Every model that we have is specific to each user.
So in about depending on the use case, about five to eight bargains, we're seeing that the models are reaching a level of maturity that we have now gathered enough behavioral data about you to make decisions going forward. So that's the learning period. It's really simple. Like five to eight, sometimes less, sometimes more.
It all depends on, different factors. But usually that window, that's when we have enough data and then we can let somebody without ever stepping them up again.
Jeff: It sounds very cool, like so.
Jim: Mario. So what I think is cool about that is, I've always looked at authentication and as a best practice being a balance of security and usability. And so you and I have talked a lot about the soft line, which is that you've really got a big focus on usability, but obviously you can only focus on usability. Just make this system easy to use. It also has to be secure, especially when you're talking about systems with highly confidential data or where you're doing financial transactions. So, we've talked a lot about this usability and user experience, if you will, and you kind of came up top five drivers for a good authentication user experience was kind of hoping you could kind of talk through those top five today. I think those should be really valuable for our listeners to hear about.
Mario: Sure, we talk about that. But really, it's simple. I mean, there's the top five will summarize them and then we'll get into the details.
But authentication needs to be fast. It also needs to be easy. Accuracy is very important as well. You want to make sure that the right people are getting access and not the wrong people. Also needs to be intelligence and needs a level of flexibility. Now to go back the responsiveness like the speed of your authentication system, especially when you're looking for the B to C use case, when you're dealing with the external world and you're dealing with customers, the responsiveness of a system is very critical. If it's going to take, let's say, 30 seconds for me to access your bank vs., maybe five seconds from you to access somebody else's bank, and you have fundamentally the same products, the same interest or same interest rates and everything else is the same. The only difference is the usability. So if I can get into one system a little bit easier than I can another. That’s a competitive advantage when I'm 80, deviate from working with one company because, the system isn't as responsive. It's slow, it's clunky. I'm going to go with another bank that's a little bit quicker and it gets me on with my digital life a lot quicker.
Jim: So what are the factors that you think may make for faster authentication? Because, just as you're talking about us I had thinking. when I authenticate to certain applications here recording from home. But if I record off or authenticate from my home network, it's kind of slow. But if I were at a public location where they had a free Wi-Fi, sometimes it's extremely fast. So it seems like the speed of my network connection has a big impact. But I think you're talking about something else.
Mario: Absolutely. You're really talking about the architecture behind the scenes. So, there's everything from the database all the way up and then all the logic that sitting on that on a log in speed, for example. So there's a lot of layers to it's that ultimately lead to a better response time.
Jim: So is it your experience that, the logic that needs to sits on the client, that is something that slows down the process, that's something that's required to give us an idea of what you're talking about there?
Mario: Yes, certainly. So responsiveness and the amount of time that it takes for a system to respond to volunteering my credentials, I'm expecting something to come back to me with a decision very quickly.
So all the systems that are kind of sitting behind that log in screen. They really need to be running on an Internet scale. You have to be able to architect the systems to really minimize any sort of bottlenecks.
So there can be bottlenecks on a database or could be bottlenecks, on the UI design. There can even be bottlenecks with the challenges that you're asking me to go through during authentication process. So there's not only the speed, the responsiveness, but and also the challenges that, I'm have to go through to get into a system. So if we can find a way to one, make sure that the systems powering all these decisions are scalable. That they're responding quickly and they can handle high volume of requests at once. That's gonna be important. But then also not making everybody, let's say, go to an estimates token for every authentication or every time I go from home to work. Now I have to do a thumbprint or face scan. So it's using it. It's intelligently authenticating me and it's only step in the up when it's required.
So there are really two aspects that we look at for the quickness of an authentication system.
Jim: Let me ask you a deeper question on, fast from authentication standpoint, how much does the level of encryption over a password, for example, would that impact the time to authenticate? So if I'm using a really advanced encryption methodology, does that have much been impact?
Mario: It could.
Absolutely could and also depends on how their passwords being handled. So depending on the mechanism that's using the back end and of course you can.
There's again, there's that threshold of responsiveness and insecurity. So you need to find the balance in the backend system, But then.
Sorry, I screwed up.
Jim: No worries, go ahead, where do you want to go back from? You want me to ask that question again?
Mario: Yeah, Say that again?
Jim: Ok. No worries. So I've got a question, Mario. How much does a level of encryption of a password have an impact on how fast and authentication would be? So. For example, if my credential store I use a really complex hashing algorithm for encrypting my password? Is that something that could impact the fastness of my authentication?
Mario: Yeah, potentially it could. Again, you need to find a balance between security and user experience.
So if you're going through a very expensive encryption process for maybe something that's not a highly secure or high value asset, you may be using too many cycles, too many, and the encryption process may be too expensive for what you're what you're securing. But the encryption method is one factor that plays into this. And also where you're doing the encryption or hashing is special. We're talking about hashing. But if we're talking about class, which is better to use hash than encryption, but depending on where you're doing, the hash also comes into play. So maybe if you're doing the hashing and client side before you send the password down and comparing hashes, you may say some time there. Now if you're doing the hashing on the server side. Now, of course, you're getting a lot of requests in at one time in all this. This one server has to do all of this work. You have to take that into consideration because now your servers are being overloaded, because now it has to do hashing functions and then do the comparison and then send back response. So that's absolutely one point of a bottleneck, too.
Jim: Ok, great. So moving on your five keys to next one you talk about was easy. I think what you're talking about here is that the user experience needs to be I mean, the other word for easy in my book would be intuitive. I can look at a screen where I know what to do. What? Well, you're talking about there.
Mario: I mean, listen, life is very difficult as it is, getting on with our digital lives and getting onto our bank accounts shouldn't be that difficult. Their technology is incredibly intelligent and it has potential to be even more intelligent. So we should be able to easily access our technology without a lot of hoops to go through, so to speak. So basically, we go to a log in screen. It's intuitive.
You know exactly what you need to do and you should not have to be challenged if it's just unnecessary, so, exactly. Intuitive interfaces, extremely important, too. And on top of that, when we are challenged for step up, maybe I'm sure we're all familiar with these captions Click on all the images that have a bunny rabbit in there.
Jeff: Yeah, I'm not a robot.
This is a very hard time telling people you're not a robot. That's exactly what a robot would say.
Mario: That's true. But, it's not exactly easy to go through a capture. So, you know, that all plays into this where we should be able to easily access our technology without all these complicated hoops and picking out these images. It's not a good experience.
Jim: I kind of feel like with step up, one of the things that you have to do. You have to think about your audience and what they're going to be familiar with. Everybody's familiar with the SMS One time tokens, one time passwords. But that's not the most secure mechanism, for example, authenticator applications. I just, try to picture my dad using an authenticator application and, he would get fresher and not know what to do. It's somebody who's in an office environment all day. That's something that they probably have experience somewhere along the way.
Mario: That's right. And that's one extra app that you have to maintain on your device, too.
For example, it I'll have a banking application and then I also have a Google Authenticator or a Microsoft authenticator. So the manage two applications, one, so I can get it to my bank and then another one so I can get the secured tokens to put back into the other application rather than having everything integrated into one where the authenticator is kind of a deployed authenticator, It's part of the banking application, for example. It's just not so easy.
Jeff: I think that's a great approach. I mean, I'm looking at my phone now and I have four different authenticators.
I have Microsoft, I have Google, I have a last past one. And then, of course, I have lost my most important one, which is the one that secures my World of Warcraft account.
So the other ones, I don't care if those get hacked, but don't mess with my wallet, it’s built into the app.
I think that makes it just a much better user experience for the user. But I also think that there is a component here where some organizations they get focused on and this is what we're going to offer this one single mechanism. And I think, people need to consider, Jim's dad in this example where there may need to support a variety of mechanisms for that step up authentication to make sure that your users can take advantage of it and that they are getting the user experience that works best for them.
Is that really a one size fits all scenario? sometimes.
Mario: Absolutely and not to make this too sassy, but there's one thing that we take very seriously at Callsign.
So are our solutions extremely flexible so that we can deploy it and make sure that the right people are getting the right authenticators at the right time? It's because we understand and everybody has to understand that not everybody understands things that the same way and that everyone has access to the same technology either, my dad not too late to call him out here, but he can't use authenticator app. So maybe in that case, we need to do an outbound call or we need to do something else for people like that.
So authenticator apps wouldn't be good for Jim's dad that or my dad.
Mario: Mario. The third item that you had was in your five factors for good authentication. User experience was accuracy just growing to me. I was actually thinking what you mean by accuracy is, it's almost like the opposite of easy. So I wanted to be easy to log in. But if I went to my bank's Web site and they said, log in with your Facebook, I'd be like, you got be kidding me. In fact, as a security guy, I went to my bank's Web site and they offer two factor authentication. I freak out. I probably would change banks just because I realized I usernames and passwords are just not enough to secure my finances. So what kind of did you mean by accuracy? Is it does it have anything to do with that building user confidence?
Mario: First of all, if your bank is using a Facebook authenticator or social authenticate, I would say move your money out of there. But chances are somebody. So.
Jeff: Before we get to about that, what about Apple? So Apple just launched their credit card and it's really a Goldman Sachs credit card.
But you log in with your iPhone and the whole catch there is that they feel that's more secure because they it drives people towards Apple Pay and virtualized credit card numbers.
But you don't really log in to an account, so to speak.
It's just really your account, which does have M.F.A., right.
I think that's one of the requirements to have the Apple card is that your icon does have to have M.F.A... Maybe I'll shoot myself in the foot here as I as I bring it up.
But I think they're an interesting use case because they're so heavily tied to the IOS ecosystem and kind of pulling that together. I think it's also a great way to lock in people iPhones because you can't really use the other apple cart outside of the iPhone experience.
You can't pay a bill without calling them. I mean, there are a lot of things that are kind of missing from a traditional finance experience with it.
If you've a chance to take a look at better yet or not,.
Mario: You've only heard about it at a high level. But in general, the world is changing right now. The whole banking industry is changing. There's a whole series, a whole collection, a whole new group of these neo-banks, these challenger banks that are changing the way that they're authenticating users are changing the way that users are registering for accounts and are really changing the way that people are banking. And Apple is just one example of them as well. And it's very interesting. And it's going to be very interesting to see what happens in this space as well, because, again, not only a change you're making, but they're also changing all these security processes as well. And they're making they're making our devices, our phones really more and more critical. And it's not just banking. I mean, even in the automotive industry, too. Now, I think Lincoln is coming out next year with the iPhone is Keys right now. My phone is accessing is it's going to be critical for me to access my bank to top my phone is going to be access, critical need to access and even drive my car and even to access locks at home. No Bluetooth technology or NFC. I'm able to unlock my door, lock it, open it, and get it. So really changing the whole experience and really finding us to physical devices. So not only the authentication changing, but then we also need to look at how are we binding physical people and how are we acknowledging who these people are first doing? How are we registering them? Make sure we get the right people and not bots or malicious people. And then how are we linking a person to a device that we do improper maintenance going forward and doing a strong link, let's say, every 30 to 90 days to make sure that this phone still belongs to this person, right?
Jeff: Yeah. I don't wanna get too far off the thinking, but I think it does point to accuracy for that authentication stuff because the phone is a key thing is interesting to me.
So I have two cars that use phones as keys and I don't have to authenticate to my phone to unlock the car. I just have to be near it from a proximity standpoint, as long as I have the phone with me. I can start the car and drive away.
So if someone stole my phone, then there really isn't a check at that point to make sure that it's actually Jeff and his phone in the car and not Jim with Jeff's phone in the car.
And it works for both of those. It's very interesting way to kind of approach it.
Jim: What I think about that, Jeff, is that no more or less secure than a key. That's right, more convenient because your phone is dead. It's probably more convenient.
Jeff: And there's physical backup compliance, too.
And in that way the card proximity card, that kind of thing is typically the backup for a phone is key if it's not an actual key. So I have both of those as well. But I decided it was, that's kind of interesting way to talk about, Mario. Come on, binding people to devices. I think that's a super interesting topic that's going to get more and more important as we go along.
Mario: And, the point about the key is very true. But at least with these smart devices, we have the opportunity to know and make sure that the right person is in possession of that device.
Jeff: I mean, you use the device characteristics, right? Make the case. And I walk the way accelerometers report and things like that.
I think it's super interesting. Number four on your list here was intelligence, can you talk about what you mean by that.
Mario: intelligence, It was basically the ability to understand and recognize various threats.
So what I mean by a threat is maybe, there’s a threat-intel platform that is recognizing that there's so much denial of service attack or some other attack coming from a certain IP range. Now, as a main, we're seeing that somebody is trying to access our systems from that IP range. Well, we should be able to recognize these real threats that are out in a while and then sort of adapt our authentication journey based on this external feed, this risk signal and say, all right, you know, username and password are checking out. But maybe this is coming from a suspicious location because of what's going on currently. We'll step you up. Also have the ability to recognize whether or not there's bots that are trying to register and open up accounts, with synthetic identities or even somebody malicious got access to hack identities. And now they're trying to right for accounts or even log on with, the credentials. So if the systems need to be able to bring in a level of intelligence from various sources and make accurate decisions based on these, we even know if I'm trying to log into a system and my email address is found on “have I been on” .com, because it was leaked on some other hack last year.
That should signal that this idea is a little bit risky because it was found on the phone as part of this hack now just set me up or change my logging journey somehow a little bit because of slightly more risk. That's what I mean about intelligence, really being able to detect threats from real people and then, and adapt.
Jim: I mean, personally, I think this is one of the big reasons why developers should not go down the path of trying to build their own authentication system or use whatever kind of free utilities are out there for authentication or build into their server container. And they need to look at, full-fledged IAM Systems, because the so many threats are changing over time and you need to continuously adapt them. That's why it's better to get a tool built by a company that's focused on nothing but securing the authentication journey.
Mario: You're right, Jim. I mean, the developers are working in organizations; they have business apps and really cool apps.
They want to be working on it. There's no way that they can be keeping up with all of the changing business requirements, and also, by the way, they continue to develop the security system and adapt for all these new threats, as well as stay on top of all the brand new technology with A.I.
It makes sense to delegates in certain areas to the experts. And these other organizations hone in and get all their fraud. And security experts work on encryption systems. So work on authentication systems. And then you have developers focused solely on sure that they're getting the best possible applications for the business.
Jim: Absolutely. So number five was flexible. What were you thinking there in terms of flexibility, as you know? In my mind, I started going over to the flexibility on the app developer side. But we're talking about the user experience here. So what about the authentication user experience seems to be flexible?
Mario: Yes. So I think, we kind of start to bleed into it a little bit. We're talking about easiness, but flexibility is really bending and flexing on different things.
So not only on risk and intelligence, but, maybe as a user, consent is going to be more and more of a hot topic. As a user, I do not consent to you as a corporation having access to certain data about me. So maybe you're using a fingerprint authenticator, Well, I don't feel safe using the fingerprint authenticator. So I don't want I don't consent to doing that organization. OK, well, you don't want to lose customers. So your system should be able to flex enough and say, well, fingerprint authenticator is not authorized for this user.
Let's flex to something else and use a different sort of authentication mechanism, work with them down a different flow. So we're still getting the same level of authentication and making sure that we are accurately identifying this person, even though they said no to fingerprints. So maybe they want to use behavioral based only. So the system needs to be able to recognize that and really respect the user's consent choices on what they're OK using with you. OK, giving us as an organization.
Jim: Absolutely. So, just to kind of touch on the flexibility does thinking of, applications are built by developers and they. And primarily what we've been talking about here today is the external type websites and phone apps and things like that. But customer facing or maybe partner facing, not employee facing. I think it's pretty clear that the Samuel 2 standard plus the emerging standard or it's not really an emerging standard, but OpenID Connect, but it's becoming more and more commonplace in the enterprise. But in my experience anyway, Samuel 2.0 is has got the lion's share of integrations for internal but from an external developer building an important e-commerce or application facing my customers.
I want to interact. I want to control the user experience. I wanted it to be strongly branded. I wanted to look like the rest of my application will want the customer to feel like they left my Web site to go authenticate and then they're coming back. You know, obviously, the social I.D. stuff is now where we're talking about here. We're talking about stuff that has to be secured beyond that. But I want to control that experience. I want it to exist within my front end and I want to interface with an authentication system using API. So what are your thoughts there? I mean, what are you seeing?
Mario: You're right. The ability to have a solution that can easily fit in to your current system is also very important.
So again, as you're integrating a system properly documented APIs so developers can easily integrate; your solution is going to be very critical for technology adoption. So there's also that aspect to this flexibility from the user perspective and it's also flexibility from the developer’s internal perspective as well for them. Now love your technology and want to work with it because not only is it providing a proper level of security, but it's also fun and easy to work with. We don't need to burden these developers with complicated SDK and complicated APIs. Package everything up, abstracted appropriately, and then provide a powerful documentation, swagger, documentation where they can interact with the guys, understand technology make that work and then integrate it easily. It's also very importance.
Jeff: Wise words, Mario. I think sometimes a lot of times developers kind of take it upon their shoulders to do things.
And I think that's where governance tends to play a role as part of the overall security. And IAM strategy making sure that there is a unified approach to doing that, or at least a standardized approach to making sure that people are taking advantage of the best practices when it comes to authentication, even authorization, those sorts of things, and trying to make sure that, like you said before.
The developers are building the best application they can using the best security that's available to them from an organization like perspective instead of spinning something up of their own, I think we'll probably leave it there for now.
So I'm going to recap Mario's top five authentication things for a better experience, which I'm sure you want to trademark that name very fast, easy, accurate, intelligent and flexible. All things I think that, pretty much anyone could agree with.
So certainly appreciate your thoughts on that. So I want to thank you for joining us here. And for folks who are interested in learning more about Callsign what they do, you can find them on the firstname.lastname@example.org. Also want to give a shout out to listener Neil who showed us an e-mail this morning. A round of questions he had around the management of identity in a multi-cloud environment. That's a topic that Jim and I are going to talk about in an upcoming episode. So I want to stay tuned for that. And as always, if there are any other questions or feedback, you can always send them over to email@example.com. Mario thanks for joining us.
Mario: Thank you for having me. This is great.
Jim: Mario, if somebody wanted to reach out to you. What's the best way is a Twitter or email?
Mario: Yeah, absolutely. You can follow me in LinkedIn name is Mario Dusaj. So and you can e-mail me directly at my Callsign address. It's Mario.firstname.lastname@example.org.
Jeff: And I'll be sure to put some this information in the show notes as well so people can find it there.
All right, so we're going to call it for this week. Appreciate everyone that's listening out there. Feel free to share the news like subscribe. Five star ratings. tell Jim's dad, tell Mario's dad, tell all your dads and tell everyone. Certainly want to keep this going.
Jim: If you'd told my dad to leave a five star ratings follow, you say, what is that?
Jeff: What’s a star? What's a rating and what are five?
Mario: What’s a podcast?
Jeff: Exactly, all right. Thanks, everybody, for listening. And we'll talk to you down the road.