See full event listing

We Don’t Need No Stinking Passwords

Passwords are like underwear. You should change them regularly, and you shouldn’t share them with anyone.

Passwords are a pain. They’re hard to remember, they’re easy to crack, and they’re a major security risk. So why do we still use them?

In this presentation, we’ll argue that we don’t need passwords anymore. We’ll explore a variety of passwordless authentication methods, and we’ll show how they can be more secure, more convenient, and more user-friendly than passwords.

We’ll also discuss the challenges of implementing passwordless authentication, and we’ll offer some tips for getting started.

So come join us for a presentation that will make you say, “We don’t need no stinking passwords!

Vinicius Campitelli has been a software developer for 15 years, working on dozens of projects in areas such as email marketing, network automation, cybersecurity, video streaming and e-learning, where he even founded a company.

As a Developer Relations Engineer at FusionAuth, he helps developers build secure and scalable authentication and authorization solutions. He is also one of the organizers of a local PHP community in Sao Paulo, Brazil.


Vinicius Campitelli 5:27
Thanks, Dan. like to welcome you all. Thank you, Dan. Thank you, Brian, for the opportunity. Dan already introduced me my name is Vinicius Campitelli, you can say whatever you, you can. I’m from Brazil, I live in San Paulo, like then also mentioned, I’m here today to talk to you guys about something that we all hate, which is, right. So we don’t need the 10 anymore. We haven’t actually needed them for a while now, because of this standard. Even though it’s a standard that has been around for a couple of years. It’s still at early stages of adoption. But I’ll get into it. So what we’re going to see here, what we’re going to talk about here, basically, we’re here, lost my purse that I lost my my focus here on my keyboard. Sorry about that. So we will go over what is web authn, we also cover, I do care why it is standard about what’s going on? We’ve entered it. What does it look like? What it doesn’t look like? But actually, there’s so we also see what can be used with trouble work with web authn. What are the protocols involved, actually, is web open protocol, which is a standard protocol does have something that goes alongside with it. We’ll see. In just a few slides, we will see about something called ceremonies, what are ceremonies and what are the sermons that are, are happening in web offense. So that is something that we’ll cover as well. And finally, how you can implement it in the guys are going to see that it’s actually really easy to implement. So at least the browser stuff, the project stuff is pretty easy to implement. I’ll tell you something, the back end stuff, it’s a bit harder.

Vinicius Campitelli 7:35
So let’s start saying what is web authn. It’s another way to authenticate. So things invasion of computers of personal computers, we do have a way of authenticating ourselves. The web authn is just another way to authenticate, right? It requires something called an authenticator. We’re going to get a good look of of this decent health indicator in a few slides. So there’s record there, the information that we require something called an authenticator is authenticator to stay home, a great part of the cryptography, the private keys, we’re gonna see about them in a few minutes. And it’s what actually the browser’s interact with, but we’ll get to it. So hold on a bit. And like I said, it the main purposes of web authn is to remove the need of a password. So I’m going to go about a bit about the history of passwords and why password things, and why we don’t need stinking passwords anymore. But the idea is, the idea is to replace passwords when authenticating us. Though, it’s pretty much all about standards. So I’ll talk to you guys in a bit about who created who is maintaining this protocol. So you guys want to see that it’s all about standards. And why is that secure? How can we replace passwords with stuffing and still maintain the security? It’s because we use public and private key players, right? So we use asymmetric cryptography to handle the authentication process. And I’ll tell you guys, why’s why that something of concern why is that something that you want to do in our apps just start this off talk a bit to explain a little bit of something called a man in the middle attack.

Vinicius Campitelli 9:39
So imagine that that there is someone named Alice and Alice wants to talk to Bob. If you guys are not familiar with these names, they are very commonly in cryptography right. So instead of saying person wants to communicate with another person or system A wants to talk to system B, with just creating a few placeholders But when he bought back these placeholders, so if Alice wants to send a message, let’s say a message called M, bought, right, so when Bob receives that message, how does he know that someone hasn’t tempered that message. So imagine there’s another one other person in the middle of Mallory have a placeholder here for stuff that Mallory is. An intruder is someone that has an evil goal. And it’s eavesdropping, the communication but not only eavesdropping. It’s actually replacing modifying the message that Alice was about to sandbar. So instead of the passage M, Mallory, capture that message, and change it a bit or changes the entire message.

Vinicius Campitelli 10:44
And then another message. So I’ll just bought note that that message really came for us.

Vinicius Campitelli 10:52
There, we have public and private key pair. So imagine the Alice generated a key pair, public and a private key, Alice would need to send her key to Bob. So Bob would start Alice Q, in, in his theory assistant in his application, there are a lot of algorithms to do that. Probably the most common is the Hellman key exchange. But in this scenario, Alice would have her key pair her private parts of the keeper, curve her in her own device, and Bob would have Alice’s goalkeeper. So whenever Alice wants to talk to Bob wants to send a message to Bob, she would send a message and time her message with her private key, the signature. For those of you who don’t know, the signature is hash for the message. But it’s, it’s an authenticated hash. So we use the private key from Alice to generate a hash isn’t on the private key. But Bob has also been keeper. So Bob can use that book key to check the signature to validate the signature. So whenever Bob receives a message, you will receive both the message and the signature. He texts the signature as part part of the paper to check if they match. So if they don’t match, which would be the case, if Mallory or someone else will do stuffing words in the middle, like changing the message, the signature wouldn’t match. Because Mallory doesn’t have Alice’s private key private key is private, because you don’t need to send it, you will have to start somewhere secure in your servers, your server, your device, your theater, your phone or something like that. So even if Mallory could be somewhere in the middle, like I said, it’s called a man in the middle attack. So if Mallory is eavesdropping, the network connection is attacking the Wi Fi or something like that. Mary doesn’t have as private keys, so he can’t generate another signature for that message. So when that message comes to Bob, Bob is going to check the signature, and they wouldn’t match. So Bob could start a signature. And hey, that, hey, is not what I’m expecting. You’re not Alice. So I’m done talking to you. So that’s pretty much what private key cryptography for, like I said, asymmetric cryptography is all about, right.

Vinicius Campitelli 13:35
And this is the main standard for SSH for TLS. And a lot of secure communications all around the internet nowadays. So it’s something that relies on have heavy math to actually do some calculations. We have multiple mortgages, comorbidities are RSA and elliptic curves, which require a large power component computational power to actually calculate the large numbers or just 30 degree equations into something very hard to do with the computers that we have nowadays. So is the most secure way of talking to other computers or these systems. Actually, we have quantum computers in our house. But let’s hope we can have a few more years of this general cryptography right now. So the signature wouldn’t match and Bob would be the starting that. So this is what public private key cryptography is all about. Right? And that is what we have often uses under Jihoon. But before actually going into that, then we talk about bit something about something called Fido. Fido is a global organization. It was created in the 2012 a 2012 July doesn’t work. And I’m staking. It stands for fast identity online. So it’s running for fast identity online. It was a joint effort between each companies. If I remember, the people in Lenovo, what are some of the companies there? There were there in the beginning for Fido. And their main goal was work with protocol for authentication, without passwords. So they would call it password less authentication. And some of the later, Google and Yubico joins, and are you guys doing Yubico. But it’s a huge company that creates cryptographic keys. Everybody knows what Google so in join the FIDO Alliance is the that organization, but their goal was to create another protocol. They weren’t, they didn’t join the phyto. Alliance to work on the password less protocol to join to develop a second factor protocol. Google started using that protocol with their employees back then in 2013. And so finally, like I said, about standards is all about creating passwords, authentication process, and protocols. They’re secure. And they’re user usable for the web. So actually, this is part of an hour called Vital to vital choose the second version of a standard. And it’s also a part of two other protocols. So web authn is just one protocol. It has a complimentary protocol there, we’ll just take a quick look at it. We won’t get much to deal with that. But basically, web authn is a joint effort between vital allies. And so that’s what we’ll see. For those who don’t know is the World Wide Web Consortium, pretty much is the organization that is responsible for web standards like HTML, CSS, and XML. And their goal when they decided to join Fido gnarly to create this protocol, or to standardize their protocol across all web browsers. Right. So this joint effort is joint vamper, would become what we know as final should. Like I said, it’s something that we still haven’t heard about a lot. When I say we, like the among developers that aren’t much aware of crypto, but it’s actually been awhile for for a few years, right. So it’s been around for a few years now, was first limited to damages to in 2015. So eight years ago, it was the first draft we had achieved. It’s the candidate status for this specification in 18 2018. And it was finally standardized in 2019. So it’s been alive for at least four years of stable release, right? Okay, so besides web authn, there is another protocol called CTAP. And I’ll show you guys in the next few slides, what’s the difference between web authn and CTAP? What do they do and how they can complement themselves? Imagine that you have an online store, we’ll call it a possible supplement store, because we’re good at naming stuff. So we have online towards the cosmos comm store, you want to sell some stuff. So you communicate with the browser, right? Yeah, HTTPS I hope if you don’t use EGS in 2023 plus two, Let’s Encrypt been there for a while. Caddy has been there for a while. So please use HTTPS, your websites, your API’s in whatever backends you have, and your front ends as well. And the browser is going to communicate with something called the authenticator with you guys earlier about the authenticator, how you want to explain much of it, but it’s kind of a physical device or virtual device that we will publish, but we’ll get into that in a few minutes. So patients, so pretty much that’s what the user will interact with. The user will interact with the authenticator, the authenticator will direct the browser and the browser is going to interact with your phone Mind store which are right. So web authn is all about this part of browser in your app communicating with so web authn, just about that, and see that it’s the other part of the stack. Right? So sedap is about the protocol between the browser in the authenticator. Actually, sea tap is an acronym for clients to authenticator protocol. So pretty straightforward, right? Let’s see what they do. So we do have these two protocols that go alongside each other. We’re not developing browsers here. No module, guys, but I’m not. And I’m not developing any hardware devices to hold the values. So I won’t talk much about C tab. I’ll focus on my mouse. But nobody asked me, Hey, do I need? Yeah, buddies already have a login process? Sorry, I had to have a form there with user and password, already implemented two factor authentication via email or via push notification or via a Google Authenticator app or something like that. So why do I need to change my app to do that? So again, let’s go back to our star, or Cosmos Wildstar, where people want to buy technical things. stuff, right. But they have to log in, right. So pretty much what ERP already does. So they have to log in to see their status to see the history for the purchase they made to save the maintenance that they do want to buy in the future, like clown hoses, or that maybe they want to purchase some funny hats, or their own circles. But you want to focus on we are already your audience, not someone that is a heavy user, not a hard user for the computers are in smartphones, or something like that. So it’s not a tech savvy people. So they’re not tech savvy nowadays, so you want to ensure that the users can log in because you need to protect the resources. But you also have to make sure that things are easy to login. Because one of the most frustrating things that we have is when we are about to buy something, and we have to login. And we forget password. So we have to go there and recover a password that sends us an email. We don’t have passwords to access anymore. It’s an old email that really like 15 years ago, we don’t remember the password. So not easy, right? Backwards are not easy passwords. They have been around since the mid 60s. So passwords are on for six years now. And they are hard. Yeah, hard to balance for a user. Because especially for users, they’re not heavy users, like I said, because they can be simple enough, because otherwise other people would guess it. Funny story here in Brazil, last month, there was a there was a data breach. And like our DOJ, the equivalent for our US DOJ was a data breach. And the hacker just went to do to the jury. And he said that he found passwords like 123 change in Brazil’s DOJ, someone really left out 123 Change Password there. So that, but that’s what should be simple enough for the user to remember. And at the same time, they should be hard enough or awkward or system or someone who doesn’t crack it. So people take the ball for years or 1000s of years to crack a password. So it’s really it’s very hard to get this right amount of badness. One curiosity. I don’t know if you guys know about it. I hope you do. But there is this website called have I been pounds and website I suggested just that if you don’t know it, please register yourself there. It’s pretty much a unique location that that informs people that tells people when there’s a data breach with their email. So if your email has ever been hacked, ever, ever been partnered is gone notify you’re saying hey, your password has been leaked. Data Breach phone company X. So please go there and change your password. Make sure to change all the passwords as well. So it’s a great website. And it has 12 point 6 billion. But the accounts account stuff have been leakage there. So passwords are heart. They get reused, right people use the same password. I don’t know you guys, if you guys do that, please don’t don’t use the same password, right? Create different passwords for for your, for your different services. So, just to prove your i this D, the first digital password that we have record off was ziens t 6561. Sorry, 61. System from MIT called CTSS. If I’m not mistaken, supposed to mean compatible time sharing system. So it was the first system to ever use a password. And the first data breach was in 65, in that same system. So the first reason to ever use a password was the same system to have ever have a data breach or the password. So interesting, right? That’s why I said that password stinks as easy to get, get a breach, get a data validation, get a leakage or something like that. So then everyone else like the bar, or the it cloud with each cloud would love to put their hands on the basis that would have passwords, or backups that aren’t encrypted with hazard passwords.

Vinicius Campitelli 26:41
So we should go through shorter alternatives, right. So what are the alternatives that we have? And thinking about it actually, the thing they stick to because for, like I said, for people that are very tech savvy,

Speaker 1 27:00
if they use a password manager, don’t think that no hard end users use a password manager. But if they decide to use one, it’s very hard to get the right. And, yeah, a lot of options in the market. But if you are, if you don’t have a central server, like a bouncer, you’re going to have different passwords on your phone or on your laptop, or tablet, or desktop, or home, or desktop for your workstation or something like that. So it’s very hard to synchronize all those passwords, right? And other thing, who watch the watchers, right? There has been a lot of data breaches in those password managers as well, because it’s a very, very valuable product, right? So imagine, for for those scared, folks, for those clowns, those scary folks, right? From the previous slide, they will just go after this is solutions, because they they store passwords for 1000s, or millions of millions of users. So they’re very, very valuable targets. And I’ve been using password managers for a while now. And some sites, they don’t work well. Because if the farmer logging doesn’t have a very good experience, I don’t mean their their farm fields correctly. So maybe the app doesn’t know about it and can’t autofill the password, because he actually can see that there is a login there with a username and password combo. Or maybe there are some forms that first ask your email or your user. And the next step is going to ask er your password. So some non standard login forms can break those those apps as well. So have trouble Derek, cop, copy, and paste. So it’s not very soft, very good experience for the user. Okay, but I can add a second factor of vacation, right? So I can multi factor authentication is that it’s great. You should add multi factor multi factor authentication to your apps. But again, it’s another very hard thing to get right because of the US. Because we can have some experiences that aren’t that great. Like, hey, I’m about to buy something, I need to grab my username, my password and any children my phone, hoping the authenticator app and type of goes from there like a six digit code or something like that. Or I receive according my email, I decode those, those long time passwords which what are these codes are about? They have a window of time window that they are valid. So maybe if you’re blocked On your computer or your device is not synchronized, it’s gonna get you wrong code. So not that easy. But again, you should add even with two factor authentication, there are some methods that are that they like SMS. SMS are, are very widespread, but they have some security flaws. Especially when, when targeting some other countries that use some older versions for the protocol. Again, here in Brazil, a couple of years back, we had a minister who has his data, who has his cell phone hacked with some, it’s due to some SMS flaws to take care of when sending codes. The SMS prefer emails or push notifications are the standard Google Authenticator app that of SMS. Users can be fished, right, you users can receive a phishing email, saying something asked me something. So very easy thing to do that just called some, I could call up the person say, Hey, you just received the call, I need to type the code here to continue if they say or continue to support, or in order to apprise author price or something like that. So there are a lot of phishing campaigns. So users can’t be fished, right. And another thing that we sometimes we forget that we also have to require two factor authentication in some scenarios, we also instead, besides just the login process, we should ask for the factor, vacations, communications, some some parts of our system that requires like a change for the car, like changing the credit card, or changing the email, or deleting the account. So those are processed, those are our workflows that should require factor authentication, we call that step up, authentication. But there aren’t a lot of people that remember to do that, it just put the two factor authentication process in their login and they forget this parts, right. So again, a great feature, but it’s easy to get lost. We could use an SSO Single Sign On process. So all all of our Asian and authorization policies would go in that system. Like everything, we don’t have bullet proofs, we don’t have silver bullets, everything as a as a problem. And in this case, is because you’re depending on the third party service, if this dish is perfect for third party process goes down, you don’t have logging anymore. Or if you have something going on with the business part and you need to deal with a new contract or something to to maybe some part of the negotiation for the new year or something like that. What happens if the third party solutions asked for double the price is three times the price that steady or are in pre. So it’s hard to depend on someone else. But again, all these things have their pros and cons. So it’s just like a matter of fed up of balancing them and and weighting them are. And that is something that I’ve often offered. So it’s useful feature of rocks here. Because web authn offers that’s the first thing it offers security. There was, like I said, it’s the same technology that is used in SSH and in TLS are the private and public key cryptography. Only available on TLS. Two, you can enable HTTP only server. So in this case, those those information data information is not being transmitted in a secure channel. So that’s very good. Another thing that we’re going to see we have something called the relying party ID and take a look at the person. The browser itself is going to validate the information that is being transmitted with the domain name for the server, or the start date that you’re browsing. So you can fish users using a site that looks like your site. Just change something the URL something because the browser itself when deeds did the domain name, it’s not part of the developer to do that. So it has a standard security process which the browser does Like I said, a lot of parts, smartphones, workers on this standard, by the way, Google PayPal Yubico, we have the W 3C, gathered stands. So very, it’s very secured. And it’s very safe to use that. And another thing that’s very cool about web authn is that the actual, meaningful piece of information stays with the use. Server side only stores public keys, like I told you guys in there, Alice and Bob communication example, right? It only stores Alice’s public. And someone tend to tend to do anything with the public, private keys to a meaningful part of education. So even if someone could get their hands on a backup, or the actual database dump for server side application, they couldn’t do anything. Because like I said, the private keys they with the user, so they have nothing just yet. That’s very cool, right? The user experience is better because the process is beating in browsers. So they would have a standard way of logging and registering e applications via browser interface. So we don’t have the different user interfaces for the login process itself. So if someone use Safari or chromium, pay for Firefox, etc, all the logging process would be the same. After logging burdens, click it. It’s all the browser that does the heavy lifting.

Vinicius Campitelli 36:42
Oh, that’s pretty cool for user experience. Another thing that there are no better studios, because you don’t use passwords, the private keys will be stored in the authenticator. And it’s phishing resistant. Like I said, the browser validates and verifies the domain name. So someone can just send you a email saying, Hey, I’m Osmose Southstar. But we could see in Cosmos, I need your password or logging here to see our latest update, or there was something wrong with your purchase, please login to see updates. You wouldn’t work closer with verify the domain name right. So and another very cool thing that I will see. Again, in a few minutes, you can combine two factors in one. And I’ll explain a bit more about it when I see when I talk about user presence versus user verification. But it can combine two aspects of security. So that’s pretty cool. Hold on to that thought. And I will get back to it in a few minutes. Another very cool thing about reablement is that T Mobile, they they went to two offers for identity diversity, a lot of guys heard of it. And they showed the report that they have implemented web elfin in their app. And they made a survey with their users. And it seems like 80% of the users using often methods instead of password. So we have a huge company with a real market base with users that actually are referring back often. And we’ll talk about what titles methods like biometrics interesting for that, instead of actually having to type. So that’s pretty cool, right?

Vinicius Campitelli 38:45
But that doesn’t work man, that doesn’t work on safari, that doesn’t work on platforms that doesn’t work on from actually this. Pretty much all the major browsers from even vs from the last five years have support for Web authn. So it’s pretty cool to hear that you can go to Can I Check for web authn, but pretty much every browser, desktop and mobile mobile devices, versions for those browsers have support for orphans. So it’s pretty widespread. Okay, so finally, Enough chitchat, let’s get more into the protocol itself. What are the problems involved in this process? I showed you guys a diagram before so you guys already know some of them. So we have the user for someone who’s trying to log into the cosmos cluster. You have the browser, everything that’s web based as a browser. So if browsers here and then we have our ads, B department SmartStop, right. So instead of saying website or API or a backhand or something like that, we have all these names right? The standard selves Standard itself calls this relying party. So every time I say relying party or RP, your bandwidth is actually the backend for cost is the his call here is called more admin for our webstore. Right? About to get some real customers buying from the store. And we have this authenticator, which again, I know that I said it 10 times before, but I’ll get to it. In a few slides I showed you guys, it’s, it’s almost there. So how does that work? How does this authentication process work for? The user will take a login button. And the browser will talk to you are your app to the JavaScript in your app front end, saying, hey, user wants to login the backend for your app to change, dude, send a challenge. A challenge is a random string of bytes. That could be really random also, don’t use timestamps or IDs or something like that. So just use whatever language or framework you’re using in your back end to to to actually generate a random string. And also, you saw me should send some other information that’s part of the protocol. I’ll do a bit of them in a few slides when I show you guys the code, but you have to send what are the relying party ID, which will be the domain or your app, like cosmos cloud started off. And we have another part of the protocol itself, you can have some constraints on which kind of, of authenticators you want to support. But let’s just call their sip. So let’s focus on the challenge the rental string challenge, and they will live by it. So the random challenge will be something like that. Just a bunch of random strings coming from their backhand. And the relying party will be the domain name for your app. Cosmos floss Then, this is where I see that comes in. So this is part of the syntax tree protocol. So the browser will talk to the authenticator, again, this is authenticator that I keep talking about, right? So the browser would, would start the protocol with the authenticator and say, Hey, I need to generate a new login process here. Here’s the relying party or D, here’s the challenge the random strings that I want you to assign. Here are some more informations about the protocol that’s about the algorithms that we use stuff like that. And the browser would say, I wouldn’t want back in a search. I will get to buy these these assertion a bit. But it’s pretty much like a signature, like the one I mentioned, the Alice and Bob communicating diagram. So the authenticator will generate a signature for that user. But wait a few slides. So these are the indicator device, which would be a hardware device or software device would ask for the user for the authentication. So that’s what the cool part of the whole financial processes all about because these authenticators they can they are already present in our, our days, right? So we have face ID, we have touch ID, we have Windows Hello, devices, we have the android android fingerprint for Android devices. So these authenticators that are sometimes teaching or devices, they’re in their head already have this biometrics. What is that? Pretty much all of us already has done it before, already did it before. So some of the kids will actually want some pinetree, or some other type of, of residence for the user could say, Hey, I’m here, and I approve this request software logging to that Cosmos plan started cough. So the data will generate a private and a public key pair, but that’s part of the registration process. I’ll get into that. But here’s the login process. So the authenticator would grab the private key that it has stored safely in his device. So remember, private key, however, doesn’t ever give the device so it’s very secure. So the authenticator uses the private key that he has ordered for the cosmos cloud store, and it signs an assertion. I’ll get into what it’s an assertion in a few moments, but it’s pretty much again like that. It’s like a That’s the natural form message. And the browser will receive that sign that assertion. So here’s what some of this stuff for web authn gets a bit nasty, because the browser wouldn’t, would have changed to send those informations to your web app. So maybe we should do a post request to an API endpoint to which those of those data with those information with those fields, and will should present the site ID assertion, which again,

Vinicius Campitelli 45:32
would be the signature that I’ll explain in a few moments. I know that I’ve been saying that a lot. Guys are patients that have to wait very well, here’s what we can go, we can grab back from the Allison Bob example, again, if possible star star, which would be your app could have the users put a key with it, right. So I’ll get back to it in a few moments. But imagine that the cosmos client store already has the public key for that user. So when that signature came, when our browser send that post request, access to our app, the cosmos can store would retrieve the public key for their users, hey, and oh, Venus’s already registered here before, here’s this, here’s his public key, I’m going to check if the signature match matches with the public key that I have stored for him. And if they do match, again, finally go there. And they welcome Vinicius, you’re now logging into the cosmos faster. So this is what the authentication, the signing process looks like. I’ll talk about the code right now. And I’ll talk about the registration process a few moments. Because we need to have a way to to take that public key to the app, right. But that’s pretty much how the login process works. So pretty straightforward, right? And the cool part for me, is this one, right? The face ID, the ID the financial. So this is what replaces Best Buy because they authenticate or want to have to ask for your, for your face or for your fingerprint. So Jesus, what replaces password, right. Let’s go back to where we were at, across to our epic clown here. And let’s get into some JavaScript. Again, it’s a browser API. So everything, like 90% of the things around in your browser with JavaScript. And the cool thing for this API is that it’s very simple. They have good naming, for their their functions, their return objects and stuff like that. So I really like using those API’s. Because they’re pretty straightforward. I need you to sign me a user, we just have to call navigator dot credential dot yet.

Vinicius Campitelli 48:18
So it’s pretty cool, right, so just in to have one call to the browser API, I’ll get into those options in the next slide. And that’s where they have lifting is going on. But as soon as you run that code in JavaScript, the browser would come in and start sit down to protocol with your team here. So from that moment forward, it’s all about that, you don’t have to worry about it. As a web developer, you just have to wait for it to come back to return a sync function. So it’s gonna, it’s gonna resolve it’s a promise that it’s going to be solved through some options, or some responses, or options. So that’s pretty easy to that options in between parenthesis they are the they are what I told you guys before about the challenge. So pretty much is an object where you will have to tell the browser what are the relying party ID remember that I said, You guys RP relying party. So it’s pretty much the domain name for your app. And you will also need to send the challenge that are backhand return it so I really recommend that you guys send the prints from the back end, instead of the front end. product doesn’t have truly random algorithm, but backends do so please just call your API and it should return a random challenge. And then you can also So ask about user verification, I’ll talk about bit. But it’s, it’s different types of testing and making sure that your user is there would have user presence and user verification. But it’s pretty much a way of making sure that we really have a human, they’re using that device that user that phone or something like that. But I expand further. So pretty much all navigator dot credentials dot get, test, all those options right here, is going to resolve, right? It’s very simple to do. The protocol itself in person has a lot of other features that you can implement here. And I’ll get a bit into that when registering. But that’s pretty much it. So pretty cool, actually. So when the results when the promise resolves, it’s gonna resolve to return this partial response, forget, it’s pretty well documented. And it has a lot of information about the authenticator about the user about the public key that’s been returned. And then if when we receive that response from the from jury, authenticator, we need to have a way of getting, which would be the process to our back end. So do a post request to our API, slash login endpoints or something like that, saying, Hey, here’s the response for the login process that you asked. Here’s the public key for the user, stuff like that. But again, and then a social response object that resolves in the promise. Here, which is a certain response is an object that has a lot of cool stuff about getting theater. So it’s an object with pretty much three entries. The first one is about the the authenticator data. So it has the relying party ID has some flags, it has the process of the process, which we will be web authentication, which will be the actual timing, it has the signature for the certificate. And so it’s pretty, pretty easy to be sold. Here. So again, there are a few nuances here, there are a few caveats here, pretty much all of this information is then returned, ie, byte arrays in JavaScript. So kind of boring and difficult to transform into into byte arrays and go back to high res, but the process itself, it’s pretty simple, right? So ancestor navigator, dot credential dot get all and then you would just note into this object, and verify and send it to your back. That’s pretty much it. I see. Whereas some people, some people are asking about the authenticator. And finally, we turn to the slides that indicate water quality indicators about so there are several types of authenticators. The three most common one our fellow harbors, which would be UB keys, or another device that you can plug in via USB, via NFC via Bluetooth. So you can connect to your computer to your phone to your laptop or something like that job, or tablet. So the good thing about this, these external hardware is that they are cross platform, right? So they work with your Windows computer, or Mac computer or Linux computer or phone if they have NFC or Bluetooth writing and plugging in USB to your phone, or if they have no job. So that’s pretty cool, because you can use the same key for different devices. So we have Yubikey. We have solo keys with Tresor. Google has Google Titan for not mistaken. They take quite a bit like maybe 20 or $30. If I’m not mistaken, here, Brazil, they’re a bit more expensive than that. But if I’m not mistaken, they’re like $30 or $10 in the US. So they’re a bigger fortune right. And they can hold hundreds of credentials they’re pretty cool chapters they did your your own operational system.

Vinicius Campitelli 54:59
They also have this kind of off, put in cages like Windows 11. If I’m not mistaken, always come from such a TPM Trusted Platform Module, which would be responsible for for storing those keys. Mac devices also come with them. So you can use Apple’s Touch ID to use to store keys. Android phones have the TPS do change that your devices have TPM T, as well. So you don’t actually need to buy those internal keys if you have devices from the past few years, like Windows 11, or newer Macs, and Android and iOS devices. So you can use the built in solutions for your own platform. That’s pretty cool, right? The only thing that I would say is different from those external hardware, they are being changed or their software, right. So not easy to get a key from Android phone on others. So we should never lose that Android phone, you are using those keys for the web authn has a new standard, that’s right to bring down synchronization for the key. So even though you’re using the building module for your device for our platform, you’re still going to be able to synchronize with the cloud and restore it if you ever use the device. So that’s pretty cool. And also, Google Chrome has a virtual device where you can enable from the, the console to for developing purposes, you can just open the console, go to Mark tools different I’m mistaken. And you can enable Web authn there any, you can create virtual devices to actually store and retrieve credential. So that’s pretty cool. I use that a lot for for developers. If you guys want to see how that how that works, just open our Chrome console and enable Web authn. Like I said, browsers, they use CTAP 2, to to communicate with those authenticators. So it’s not part of the job to talk about that. Because we’re not building devices. When I’m building browsers, we are building web apps. And that’s what well that often saw about. I know that I have a question slide here. But we will charge time, I’m going to skip it and just talk about the ceremonies. And then we can leave room for some questions. In the end, if you have time. To basically ceremonies are the process of login and registering they, they have some cryptographic features as well, which we’ll call attestation. And assertion. Basically, whenever we the browser calls the authenticator to sign a message for a login or for a restriction process. The authenticator should return a certificate using the private key that made it and that certificate has a lot of information about the device. So you can know if the Vindicator is a UB key, you can, you can make sure that your indicator is using elliptic curves, or you can make sure that your indicator is not a beautiful device or something like that. So even though you can just leave this settings, restricted, you could have stolen some sort of constraints to make things even more secure, even more restricted. But personally, I would only recommend this kind of constraints, you are creating, like a banking app or something for the government, because it requires a high level of, of, of security or something like that. Because if you know too much about the the educator, you could have some problems with the GDPR because you’re storing data for the user. So even though you could retrieve and save information about the user ice user indicator process, I don’t recommend doing so. Solid indication is, like I said, just that simple process. And the difference between registration is actually that the browser would need to send users public key to your causes cluster right? So remember, when Alice was talking to Bob needed to send her public each book is the same thing the browser needs to the browser receives the challenge from the backhand that’s done to the to the authenticator and the authenticator calls the user for ASAP pitcher do something like that, and then generates a key pair, it will be securely store the private key within the the device. And it will return the public key with a certificate to the browser. So the browser could send that public key to the back end. And then our backend should register that public key under that username. So imagine if I’m registering for Vinicius dot Capitole, at version And I receive that public key for initials, I know that every time that Mrs. Wants to logging in would have just send me some information that I can check with. If the public key so it’s pretty much the same Alice and Bob, except there are a lot of other few things that you can do, you can have several public keys are the same user, it depends on the business logic that you have. Maybe no one allowed that maybe just want the user to have a single source of login like that their app or something like that, their their phone. So if you want to allow more than one login more than one device for a common cloud store, I would say that you don’t want to have so such higher constraints or requirements for security. So you could allow the user to register several public keys for his username. That’s also pretty cool. But it’s part of our business logic for the backhand itself. And that’s part of the protocol. But it’s a fun thing to mention, right. So just this process is the cool thing is each website whenever there is a process of signing up, the authenticator is going to generate a key pair for that specific relying party. So it has private keys for Cosmos Pastore for oppo is great a con for Amazon, or for So it has different private keys for each one of those sites, right. Just to finish things up, the registration entry point for your browser API is pretty much the same.

Vinicius Campitelli 1:02:23
The differences between not get in Morris create so just called navigator dot potential rate. And you should pass desktops actions, which would be the relying party ID, user name or user, it’s been a challenge that your backend created. You can also say that you want to use elliptic curves with DSA. So that’s what that meant minus seven stands for an algorithm identifier that stands for ECDs DSA. So you can have such constraints. So that’s pretty cool as well. We’ll see the relying party the user to read the challenge from the back end. And you have some constraints about type of, of algorithm that you want to allow. Again, it’s a promise. So it’s going to resolve to the new credential info, revenue, credential info has a lot of information, like the challenge. And he also has this object called the attestation object, which has the Credential ID, the credential public key, this is the this is the object that you need to send to your backhand, right? Because you’re registering the user. So you need to send this information to the back end to the back end can store it in their database. Again, the only thing that is stored in the database is the public key. So not valuable at all. The only thing that can generate certificates are the private keys that are safely stored. Procedure. Normally, we use what about when, when registering, we need to ask some other kinds of information. So the user could ask them app could ask the username or the email to associate that public key. Right? So imagine you go to Cosmos club store, I click I want to register the store. Well, that’s okay. So what’s your username or your email? I will delete my email. And then when I hit next, we’ll send some information to the back end. The back end would return Okay, I want to register the user who is stylish and then sit up with

Vinicius Campitelli 1:04:47
Yeah, sure. Just being told that took a lot of time. Sorry about that. Monster. That, like I said, you could know a bit more of the authenticator Every indicator has a certificate. So you can go to this website right here, which is a metadata service for authenticators. So whenever there is a certificate coming in for a back end, you can see exactly exactly which authenticator was used during assess Windows Hello harder, I think gays are always coming with this specific problem. So in this JSON file, which is a huge json file, which is extremely important, it’s a base 64 encoded json file before the indicators. But again, I don’t recommend doing this attestation process to GPR. Right. And, again, yes, we can use as a second factor of authentication due to something called user presence and user verification. So user presence is when the user has access to the authenticated right, so it’s connected via USB via NFC or Bluetooth, you can go one step ahead. And that’s for, for verification or on presence. So verification will also ask for the user for a ping, or for your breed or for his face to be a face ID or something like that. So my, my tip here would be if you are just authenticating, use just verification, required verification. Because the user will have such a fingerprint, it was it would have to open the camera and says myotube to Windows Hello, or the charity or the face IDs. So if you’re getting used verification, when using as a second factor just was pressed. I won’t go over resin keys, I’m sorry. It’s pretty much a way of storing user information that either. Like I said, it’s pretty much going back from binary in JavaScript to basic support. That’s not very easy to do. But as soon as you get what, how it’s done, you get this trick. So I have to wrap things up. Again, I’m often allows users to authenticate using strong authentication protocols without passwords using fingerprints or your face. And with that users are happier because they can vote by era when the hats or funny clown noses in your store easier without having to remember Yes, password, right. Well, thank you guys. Sorry, it took so long, I had a lot of things to say. So here are some resources, you can check the Mozilla, as always has three dogs docs about the web authentication API. And here’s my, my social media handles competently. Whenever you can find Twitter, GitHub, Instagram, and Twitter off. We have a lot of guides on authentication as well. So you can check us on That’s it?

Dan Moore 1:08:24
Yes, yes. That was amazing. Thank you so much. You cover a lot. I know you had to skip some things due to time constraints, but really appreciate candy in depth. Look at that. So thank you, Denise. Yes. And thank you, everyone for joining us for this session about how we can avoid stinking passwords. So thanks for your time. And don’t forget two weeks we’ll be talking about sessions and awesome continues. And we’ll we’ll see you later.

More Awesome Sessions