I'm intu kukui. I spoke this morning about what I was advocating it's identity assurance by our own position and memory and the bad. The background is that they passwords, even though however you hate it, passwords are absolutely necessary because democracy would be dead where the password was lowest. And we were deprived of the chances of getting our position confirmed in getting our identity authenticated. And I'll be talking a bit more about two factor authentication of the application of concept to, to factor authentication. Later,
I am Raj Hegde, Dak I'm with a company called knock knock labs. We are probably best known for putting the Fido Alliance together and inventing some of the core Fido standards. We have a point of view on Martin authentication as we call it. My BI personal background have been in Silicon valley since the mid eighties worked on operating systems. AI last 20 years on security, including PKI last company I was with was PGP. So I have a perspective on privacy as well.
Hello everybody. I'm Chen. I'm from bio ID. It's a German company. I'm a Canadian. I was born in Malaysia and I'm second generation Chinese Malaysia. And my wife is one Taiwan and I live currently in Lu in Switzerland. Talk about the identity anyway. So we do biometrics as a service and since 1998, yes, I'm duo because we were one the very first to provide biometric logging for windows XP. So that tells you my age really. But anyway, so we dropped the biometric platform dependent software. About 10 years ago, we decided to go for biometric survey so that anybody can use biometrics just via API. So this is where we are. Thank you.
Hi, I'm Christian. I look after authentication at Google.
I'm Mike inin over at T-Mobile. I spent a lot of my time working both on how we bridge second factor across device reset. So Fido, some of those tools have been fantastic, but users struggle when they change devices, upgrade new phones, their phones broken stolen, and how we, how we bridge second factor in those, into those ecosystems.
Well, thank you knowing a little bit about the panel and some of the positions that are represented here. How about let's start with a little quick chat about, you know, the phyto method of local device authentication versus server based biometric authentication, and then any other comments about that as far as the bottle goes?
Sure. I think when it comes to second factor, most people think of something you have and something, you know, and so when it comes to Fido, Fido's been doing a fantastic job of kind of something you're in control of. And you can wrap together, both something you have and something, you know, is in the fingerprint sensors. And so we can get very strong signals that a user's authenticated, the right user's authenticated, or at least the user that originally bound that Fido key to their account is the one returning. And so we've been very happy with our Fido partnership.
Fido's gotten a lot of accolades for, you know, bringing biometrics to the masses and all of that, but I think, you know, the most fundamental difference in the way, you know, that kind of Fido authentication is changed. The way of thinking is bringing the authentication locally in terms of like the user's, like, I wanna say kind of personal identity, but like the, of course authentication is always between the client and the relying party and kind of the back end. Right. But, you know, I think the world would pretty much still be happy with passwords. As I think some of the folks on this panel kind of hold that outlook. If only we could have moved the authentication that part of authentication local and, and not make it remote because that single move is what solves the massive remote vision problem that we have. So I, I think by definition making, you know, kind of authentication happen locally kind of user verification, making user verification happen locally, it's kind of the right way to phrase it, I guess, is the most fundamental shift I think in authentication that we have had seen in, in S
Hello. Yeah, well, we, we are coming from a different world. We, we do a match on, on the server side and way back when PayPal and one of those founding members, they actually invited us to join fi consortium and we were thinking by, and then we decide not to be part of it. Not because P does not make sense. It's just because we have been doing biometrics in the cloud by making biometrics, the authentication available to the service provider and the, our assumption, our belief is that the decline devices will change and they, they are not, they cannot be trusted in a way. So let the users in the procession of giving a trust authentication on the device is something that we think would be a little bit risky at that time. And of course, Fido has evolved quite a bit to make the, to bring the gap together, but still we are still offering the service in the cloud to make it available to the service provider rather than to the customers directly.
I did wanna ask a follow up about that. So what special precautions do you take to secure the samples and the authentication system in the cloud since
Well, let's, let's take it that way. That for example, take the apple, I touch for example, or face ID, the, the template will be stored on the device and then the, what happened you, when you change your device and then you have to re-enroll, that's, that's one thing and how to protect the, the device from hacking. That's an issue that you have to rely on the users and 99.9% of the consumers. They are not the it experts that we are. And that we look after the data center, we look after the, the backend security. And that's why we think the, the template itself is what we really need is like the hash code that we've been talking about. And, or the, the public key that we are talking about, the private key is the initiation of the user using the, the biometrics template, the trade. Okay. So in our view, the user initiation is the private key. So to say, and the public key is the, the template that got the hash template that got so in the server,
Maybe a different perspective. I'll, I'll say what I said yesterday. There isn't a perfect authenticator out there for anyone for all use cases, universal, you know, every, every authentication mechanism comes with a set of, of attack vectors, compromised vectors, and, and, and associated pros and cons. So it's, it's incumbent to you to, to look at those carefully and understand the big difference between these two client side matches of biometrics that involve a consent oriented mechanism versus one that may be either passive or may take those templates and store them elsewhere. We often go through an imagining exercise with some of our customers, right? We, we say, look, it's one thing for someone who's a nation state to make the, the decision that the only way they can solve a class of problems that they have is by the usage of server side biometrics. And it's their prerogative.
If they get sued, they're not likely to go out of business. If, if you are a private company, then make sure that you go through the imagining exercise. If, if your central store of biometrics, for some reason was breached, maybe it's your vendor that was breached. Maybe, maybe it's your store that was breached. What are you gonna say in, in response because there's a disclosure, reasonable disclosure practice there and, and, and telling people that, oh, well it was hashed. Sometimes doesn't play very well either to the customer or to the press. I, I think that there are reasonable expectations that we have. We are not, you know, my, I, I personally say no authenticator, perfect. Make sure you understand the threat models that you're dealing with. There are issues around things like revocation or, or replacement of devices. And, and you can bring a variety of measures that, that don't have to involve server side biometrics, main wall server, side biometrics. These are all choices that you get to make. Hopefully you'll do those with a threat model in mind with a, with a sense of, of purpose in mind, rather than a set of ended representations.
Okay. SK, did you have something
On, you had a follow up thought on the while the phyto and the biometrics locally to the phone, nobody wants to store the, you know, database full of fingerprints, compromising a database full of fingerprints, just as bad as a compromised database full of passwords. But at the end of the day, we have to have something on the server still that we can go back to cuz without fail users, lose their devices, they get stolen, they get lost, they get reset. People are replacing their phones every year and a half. And it's rare. The old phone is still online. When they're trying to set up the new phone passwords, we haven't quite gotten rid of, but at the same time, they're almost irrelevant because if you haven't used your password in two years, since the last time you replaced your phone, it's not likely that you're gonna remember it. Now we have users that have pins. We have 65% of our users. Who've set their own pins. And within four months can't remember their own pin. Yeah. It's, it's not a tough,
Well, you know, I think maybe Christian can speak to, I know that Google's got a fairly extensive rollout to their customer base of two factor. They have to deal with both recovery. And, and if you, if you're a Gmail customer, you, you probably encountered what happens when they, they, they figured out some intervals in which to prompt you to keep these things fresh. So maybe you can speak to some of that. First
Off I wanna respond and say, I wish I was a mobile operator because then I would have a secure element in every single one of my user's hands. Right. I mean, there is so much more we can do with that. So that's, I guess kind of just my first statement here, right? Yes. Multifactor authentication is hard, right? Any kind of user authentication where you need to have the user involved, having to remember something or do something is tricky. You will always need to have some form of recovery. Recovery is recovery is tricky. I think we, we, I made the statement yesterday to say that even if an attacker has your Google username and your Google password and potentially knows your phone number over 99.9% of the times will still block that attacker from getting access to your like account, because we know more, we know other things about that specific IP address or about the process or about the way that the login kind of happens.
Not everyone is that fortunate. I would say that there is a lot of very, very important and large underlying parties online that doesn't necessarily maybe have that level of sophistication, which means, you know, the only way that you can really authenticate a user is based on what they provide you now. That's okay when everything goes fine. But when you end up in an account recovery situation where maybe the user forgot their password, or maybe they forgot their second factor or they lost it, or whatever the case might be, we have all this other data to fall back on. What happens if you don't have that? And of course that's not foolproof, right? I mean, 99.9% is good, but at the scale, which we operate that 0.1% is significant, right? And, and that's why we have programs and other, you know, initiatives going on such as the Google advanced protection program where we're saying, you know what, we're putting more of the owners on you, right?
We're gonna give you this ultimate level of protection account recovery is gonna be very, very, very hard, right? And there is a Jonathan, it might never succeed because if we're not quite sure, it's you trying to recover the account, there is a possibility that you will never have access to this account again. So please, please, please make sure when you set this up with multifactor, whatever the case might be, that you have taken the relevant precautions and for advanced protection, that normally means more than one physical fight authenticator because you know, there, there is this trade off and it's not the best we can do is kind of the behavioral stuff that we do behind the scenes. Of course that's always there, but in essence, you know, it, it, there's always the possibility that we will either make the wrong decision, right. Or if this is an account that you've indicated to us is a high priority and a high risk account, we are gonna have to tone our things, you know, up so far that there might never be access granted to that account ever again, if you can't successfully prove your, your authenticity or your identity to us.
And, and, and unfortunately, I don't think anyone has really figured out the, the, you know, the perfect answer to that. This is a trade off. And what we're now doing is we're letting the user pick and decide where on that scale they, they want to be. But this is a hard problem.
I think if you were at the pH session yesterday, I think Dr. Gomi laid out at least a conceptual framework for account recovery. And that's, that's worth thinking about, or looking at, I think there are, are a range of options from a second device to a, to a, an escrow kind of concept or a, or a collaborator kind of concept. There are, there are, there are a number of concepts to allow people to filter through to that very last option, which is, Hey, I have no way to prove myself other, other than in person. There there's one, there's one other concept that I'd like to mention here, which is, you know, whether it's identity systems or, or authentication systems, they all tend to have these vulnerabilities. And we often end up augmenting them with either reputational systems or risk systems of some kind. And, and that's a, that's an advanced topic if you will, perhaps not for discussion today, but, but those are certainly more prevalent in usage commercially today than most people realize.
Well, that's kind of one of the points I wanted to maybe try to include two things. First of all, Fidos bigger and not just synonymous with biometrics or even, you know, U two F do hickeys, you touch or whatnot. You know, there's other applications that can, can be used there, but also like, like Christian was getting at there's more to authentication than the authenticator. So, I mean, I think it would be worth just a couple minutes for the panel to talk about what are some of those risk factors. I tried to describe some of them yesterday and today. What are you seeing in the field are the risk factors that easily allow you to say, even though I've got the username, I've got the password, there's no way I'm gonna let this attempt go through.
Yeah. So lots of different risk factors. And obviously the carriers are a, a strong avenue of attack. Most companies out there still use SMS as a second factor. And so most attackers realize that targeting the carriers is a, is a profit worthy attack, vector given. If they can get a hold of your account, they can hit those, hit those bank accounts or drain your drain your accounts. So we're constantly evolving what we are trying to look at in the flows, trying to attack both the credential stuffers, as they're trying to find accounts, they can attack as well as when it's humans trying to, trying to break into the accounts as well. So we're looking at things like, you know, are you logging in from a, a device that's not on your band? Are you logging in from, you know, a location that's different than where your, your mailing address is? Are you, you know, why would you be logging in from international right now? So I think we're up to about 200 different data elements that we're looking at. And considering in the authentication, all of 'em serve rolling together and adaptive as you know, a big buzzword over the last several years. Right? So rolling more of that into the, into the rules, right? Second factor. Isn't one factor it's you, you've gotta take it in depth and do more than just one method. It's not just drop 'em to, you know, a pin.
Well, I just want to follow up with the comments earlier that make bike Raj Hegde about this match on server. There's a risk that people might tend to attack the server side in this way, but this is the, a different way of thinking people. I think people are largely to thinking about S as the surveillance thing. Okay. And once you have my template, you're able to identify who I am. I think this is, this is a different way of looking at the technology, but this is not what we are talking about. Talking about authentication. You want to be known that who you are and attacking the server with the template where the templates are. Resiting does not make any sense because there's a technique called liveness detection for KYC. You cannot show to the bank. I want to open a bank account and say, well, yes, my, my iPhone tells me that this is me.
I want to sign up with a bank account. The bank will say, no, I do not still do not know you. The process involved the user, the user initiation as a one factor is very important in Germany. For example, if you want to open a bank account, you have to do this video collection, okay. This is what it is because they, they need a face to face. So when people come to us, they're not asking for us, are you doing biometric, you know, match device or match server? No, they just want to say, well, we want to raise the level of assurance. This is exactly what the whole whole idea is. And the second thing is they want to make the user experience different, because if you, if the consumers, if something happen to the consumer, this is all it touches once that they realize how important it's to rely on the service that can be secured by the service provider.
This is very important. I give you one example. Before I pass on my microphone to the panel here, I was driving in Switzerland couple years ago, and I put my luggage one in the luggage rack and suddenly took it without me knowing it. And I had my passport in, in the, in there. And how can I provide identity? Fortunately, I was on my way to Geneva. I was meeting with someone Kenya friend of mine. She happens to work for the UN. So I was able to go to the, the embassy and tell the embassy. Yeah, she was the, my reference recognition in a way re that, well, this is Chen. And I got my passport almost right away, but still they try to match against my, my data in, in the, in the database. So nobody can decide on what you possess. I think this is the, the, the reality is the, the server, the service provider has to make the decision based on the, our factor and the, the initiation must come from the user. Not necessarily from whatever the user tells the, the servers,
Just turning back to the topic. Here's a conceptual framework. Authentication is a game of signals and, and there are two kinds of signals you're gonna get. There's typically a claim of some kind, there's a claim signal. And then there's some calculations that are performed on signals that you source from either the device, the network, or their historic in nature or temporal in nature of, of some sort. And, and the game that we play today when we play authentication is a game of weak signals. And the, the reason is that there are things like password, which are symmetric, shared secrets or, or IDs that can be easily forged. These are all weak signals. And, and I think maybe the way that we've compensated so far is by using an aggregation of more signals. The, the challenge with those scenarios is that often the gathering of those signals, which is typically outsourced to third parties becomes fairly privacy intrusive, right?
Because, and if you want to get a sense of this, go look at the JavaScript that's being thrust down at you in any page that's coming from, you know, pretty much any provider that's providing you some value. There are third parties that are, that are present there, gathering information from your device, from you, from your data in, in ways that are generally not desirable. So how do you shift that game? The, the important thing in, in the game of signals is to go find strong signals where you can, the reliable signals, strong signals. And, and one of the things where that Fido's done in this area is, is by saying, Hey, look, this private key associated with this, with this gesture, whether that's a token, a pin or a biometric constitutes the closest thing that you're gonna get to a strong signal, because it's coming from a sequestered area of the device, that's below the operating system. That's terribly hard to attack and most important, it's eliminating scalable attacks. It doesn't mean that an individual cannot be targeted and, and their authentication systems or, or, or mechanisms compromised. But if you see someone who's vulnerable as an individual, there are ways to step up the protections without changing the infrastructure. So remember, it's all about strong signals, wherever you can find them. And if you can do it without violating the privacy expectations of the end user, that's so much better
Questions from the audience.
I thought we can start with might. So first, thank you very much for this strong
Signals versus weeks weak signals. It is yesterday. I wasn't present, but it's shifting the view of my shifting the perspective of how I see the authentication in general, very useful thing. But I would like to get to the topic of, let's say we authenticated and now, or we cannot prove that we, or we say we are right. And now the account is locked right back to what Christian was saying. So I see two different possibilities. The account is locked, physically. Meaning that, for example, for example, I had this cryptographic key, which only can decrypt that account and it's lost permanently, right? So now the account is truly lost until we at least have quantum computers enough to whatever. Right. And the second is the policy in the company is high enough. So I have to, it's almost impossible for the individual to reach that bar.
Right? So, and, and this is so I'm using the two factor education provided by Google. And to me, honestly, like I don't have this knowledge. I was trying to read this and I don't know which type of the, of the protection you have. Like, if I lo lose my token, how can I restore the account and stuff? And actually, I think this is the entire weakness of the market. Like this is, there are a lot of legal terms in the consents and stuff, but all this defined technical distinction between, can it physically be unlocked or not, if something happens or not happens is not there. Right. Is the question understood. Does it make sense, basically, I'm trying to ask you, like, where can I find this information except asking you directly? Thank
You. Sure. Yeah. I mean, I can answer the question. Well, at least for this specific instance of multifactor authentication, you know, even if you use a security key, if you go back to like how security keys work specifically, the fighter two, either photo two protocols. I mean, it's not really signing articles. You can't really decrypt an encrypted stuff with these keys. So by the very definition, losing a security key doesn't mean physically losing a cryptographic key that unlocks an account. This is all checks and balances on the server side. So it's, it's it's policy, right? That says, well, if you don't come into the security key today, we're not gonna give you access to your account. Technically that policy could be changed. And technically those policies are changed every day. When someone submits a account recovery claim and jumps through a bunch of hoops, right?
Those hoops might be, you try to recover from an IP address that we've seen before, and maybe the machine is known to us because of other signals we have. So, so this is, this is policy. I mean, we are also at the same time, you know, think at least for me, it's kind of a bit of a dirty word, like think cryptocurrencies, right? I think blockchain, right? I mean, that's one of the weaknesses for me of like any kind of, kind of blockchain and cryptocurrency, which is not escrow, right. Which is why we're getting all these wallets. But then again, you know, if these things get compromised, you lose all your money. I mean, the, the weakness is also the strength or the strength, also the weakness, right? The fact that money is tied to some cryptographic key is wonderful because that means there's no policy that can be changed somewhere, which means you're gonna be out of your money.
But if you then lose that private key, you are dead in the water. Right. So we, we don't want to be in that position most of the time. I think there are other things, because of course, right. There's always this question about, if, you know, we can just change the policy to get access to your account. What does that mean for privacy? Right. Does that mean everyone can get access to anything? Well, I mean, these companies have strong policies internally, which kind of prohibits that kind of thing from happening, if you really want to be absolutely sure. And kind of say, well, I'm gonna provide the decryption key unless you have this physical key that I hold in my hand, no one can get access to my data. You're kind of like leaning very, very far over to the side of saying, well, you know, if I then lose that key, which we know humans are not really that great at protecting and keeping safe, there is absolutely nothing that we as a company can do. And I mean, there is certain initiative in certain places where stuff like that does make sense, but I think for general purpose account use multifactor indication. Even that's not the route that at least any one of the services that I'm familiar with has taken so far
Here. She just gave,
I wonder if you could give me a chance to speak my opinion
We're at the end of our time. So sum it up in one minute, please.
My understanding that the biometrics is good when people want the better convenience, but they it's, it's not correct to recommend. I say I have a big concern when people talk about the biometrics in terms of two multifactor authentication, which is meant for better security, all the factors for multifactor authentication must be deployed in series, not in parallel deployed in parallel, convenience would increase, but the security would decrease. And in many cases, biometrics is used with a password. There is a fall back means against the false rejection and that password. Then the biometrics are usually deployed in parallel, nothing serious, meaning increasing the convenience, bringing down security. So we should be very careful when we hear by biometrics as a factor of multifactor authentication. And the another concern I I have is that I hear some people say the mobile phone use one factor for receiving one time code by SMS is more vulnerable than the physical,
The solution by physical tokens. And if it is the case, my concern is that physical tokens tokens would be fine if we will have only a few accounts to predicted by two factor authentications. But what if we have 10 or 20 accounts to protect by two factor authentications, shall we have to carry a bunch of 10 or 20 physical tokens? Or shall we have to reuse the same token for many accounts? I have no answer for, for that. And I would like to talk about two new possibilities, one for better convenience, one for better security. Those are, we cannot satisfy both at the same time. The, the first is using two different kind of passwords, a very strong, long password supposed to not be remembered and written down on a memo should be viewed as what we have. Definitely not what we remember. So it could be used as one of the factors of two factor authentications for light duty. Can we take this off the screen two factor authentication?
Speaker 10 00:31:03 Yes. We
Start this at no cost just by verifying two passwords at a time one, we called ally and the one physically possessed. Then we could rely on the strength of remember the password against the physical theft notes slides, and also the strength of physically very long password against brutal force attack. Although this is now strong against wire tapping as token based, the solutions are with maybe PK or one time code. This could be viewed just as a thought experiment or could be actually considered for practical application in between a single factor of indication and a costly, heavily armor. The two, two factor schemes, or as a transition from the former to the letter. And second idea for better security is to apply the concept of expanded password system will advocate. We allocate random numbers and alphabets to the images shown to the users, random numbers and alphabets allocate to, to the users, the user feed those random numbers alphabets on the other devices. Okay. Then the authentications have receives the random one time numbers or alphabets from them. They recover the images that the user had registered, thus authentication can be completed for better secularity. Thank you very much. Thank you. Thanks to all the panel members.
