 Thank you so much for coming. There's a ton of great sessions going on and it's been a long two days, so thank you so much for choosing to show up. I work for a company called Twilio. I serve as a developer evangelist for them. So I don't care, I say, I don't know if you've heard of Twilio before. Oh wow, that is so cool. How many of you use Twilio in an app before? That's also great. So yeah, for those of you who haven't heard of Twilio, we're probably most known for making it really easy for developers to send and receive text messages and place and receive phone calls from inside their app. So this is how you send a text message using Twilio. So it takes about three lines to go to not counting the whitespace to send a text message. And so you can do about the same thing using phone calls. So from the large-scale applications, folks do things like build phone call centers using Twilio. From the simpler use cases, or I actually like to think like some of the more important use cases, we do things like sending selfies. Here's a lot of posts I wrote recently. And so I talked about how to press this button. It took a picture using an Arduino and a webcam and then a sense and an MMS using that. So my dog's name is Kyra and apparently she's a pretty smart and that's been pretty great. So we've always been about text messages and phone calls. This is at least what we've been most well known for. We recently announced Video, which is super cool. We're going to try to make it as easy to integrate video calling into your apps as it is to integrate SMS and phone calls into your apps. And we just announced this about a week ago. And if you'd like to get your hands on this early, we're throwing a conference in about just a little under a month. It's called Signal. It's going to be out in San Francisco. We're going to have some amazing speakers. It is a developer conference through and through. It makes some really super technical people. We're going to be talking about the tools and technologies that developers are using to fundamentally change the way that we communicate. So we're pretty excited if you are interested in going, come find me afterwards. I have a promo code of 75 dollars off of the registration. So normally when I get up and get talks, I'm talking about text messages and phone calls, at least if I'm talking about Twilio stuff. Today I'm talking about something quite a different. About two months ago, we had our first ever acquisition in the history of our company. And we joined forces with this company called Offy. And how many of you have heard of Offy before? It's almost a rhetorical question because I can't see anyone's hands anymore because of the answer. But Offy makes it really simple to integrate two-factor authentication into your apps. And I think that, you know, I've gradually over the last couple of years become more familiar with two-factor authentication. I started probably as a consumer of it through my email accounts, your Gmail, as most of you have. How many of you have two-factor auth turned on on your email account? Looks like about half. How many of you have two-factor auth turned on on accounts that are not your Gmail account? Just on other accounts? I think it's really easy, or at least it's really easy for me to always think of hacking as something that happens to other people. Okay. And fortunately, as far as I know, I haven't been hacked yet. But you've seen these, it seems like every week we're having another story of another huge compromise, security compromise, or a whole bunch of encounters. And it's easy for me to say, like, oh, I don't shop at Target, or, you know, like, oh, I haven't used experience or anything to check my credit, so I don't have to worry about that. But I've read this article in Wired a couple weeks ago that really kind of crushed me as far as possibilities for hacking, and also, like, the different attack factors that people can go. Because I always kind of thought of, you know, hacking is being the sort of thing that happens when somebody breaks the encryption or gets the master password and downloads a 14 million user account and whatnot. I read this story, though, in Wired, that kind of changed the way that I think about these things. So as a tech journalist, he has a three-letter Twitter handle, Matt MAT, and a couple hackers decided that, for the loals, they thought it would be fine to take advantage to securing his Twitter account. And so they go to his Gmail, because if you get access to someone's Gmail account, you have access to everything, right? Like, once you have access to someone's email, you can request password resets for your banks, for your Twitter account, et cetera. Matt did not have two-factor off installed on his Gmail account. And he'll talk in here and says, you know, if I had that installed, I probably could have prevented a lot of this pain and heartache. And I'm just going to read you just a little bit of this article just to give you an idea of how this hack happened. So he goes, at 433, someone called AppleCare claiming to be me. Apple says the caller reported that he couldn't get into his me.com email, which of course was my e.com email. In response, Apple issued a temporary password, despite the caller's inability to answer the security questions I had set up. And it did this after the hacker supplied only two pieces of information that anyone with an internet connection in a phone can discover. At 450, a password reset arrived in my inbox. I didn't use my me.com email, and I rarely checked it. But even if I did, I might not have noticed the message because the hackers immediately sent it to the trash. They were then able to follow that link to permanently reset my Apple ID password. At 452, a Gmail password recovered email arrived in my me.com mailbox. Two minutes later, another email arrived and notified me that my Google account password had changed. At 502, they reset my Twitter password. At 5 o'clock, they use my iCloud's findMyTool to remotely wipe my iPhone. At 501, they're remotely wiped my iPad. At 505, they remotely wiped my MacBook. Around the same time, they believe my Google account. At 510, I place a call to AppleCare. At 512, the attackers posted a message to my account on Twitter taking credit for that. Now, the most interesting part to me about this was, he says earlier, that he was able to gain access, they were able to gain access to his me.com account using two pieces of information that anyone with an internet connection can discover. So, what they did, they called up AppleCare. And AppleCare, in order to issue a temporary password, asked for his billing address, and the last four digits of the credit card, they had five on five. He was like, so, anyhow, how do you get someone's billing address? Someone who's technically savvy. Who is? Exactly right. They did a who is lookup on a domain that he had registered and he did not have who his guard put on there. Any ideas on how you get the last four digits of someone's credit card number? This one was most interesting. So, that's super interesting, because he says in the article, he goes, this is not how the hackers did it. But he goes, every single time that you call in order of pizza, you are giving the guy the pizza counter enough information to reset your Apple, because you're giving him your address and you're giving your credit card number. That's not how the hackers did it. So, the hackers go to his Amazon account and they want to do a reset, a password reset on his Amazon account. But in order to do that, you have to have all the digits of the credit card and the billing address. And so, they call up. They already have his address, right? So, they call up and say, hey, I'd like to add a new credit card to my Amazon account. Here's my billing address. Here's my email. Oh, sure. Why don't you do that? So, they give him a, you know, like a gift card or something. They hang up, they hit redial, they call back, hey, I'm locked out on my Amazon account. They're like, okay, we're going to need the entire digits of the credit card number that's associated with your account and your billing address. So, they just gave him the credit card, they just gave. And then once you sign in your Amazon account, you go, he says the same information, those last four digits of the credit card number, that me.com fills are sufficient to reset your password, are shown in plain text on Amazon site. And so, this really moved me away because this was not, this was not like one of those widespread hacks that you hear about in the news, right? Like, this was not some fundamental security breach. This was just a couple of guys who, you know, as far as you know, had very little actual technical skills. They just decided they wanted these guys to account. This is not necessarily something that, I mean, he goes on to say that they've now fixed some of these flaws and whatnot. Some of the hardest part about this was he said, he lost his entire digital like, he lost access to all of the accounts, he lost access to all the emails he'd ever had. He had a ton of pictures on his MacBook that he had not backed up, including pictures of him and his newborn baby. And so he shows this picture here. He did, the story has a kind of happy ending. He's able to recover his MacBook costing $1,500 to get all the data restored. And so he's able to get these pictures back. But he says, you know, had, I had Google two-factor off turn it off, this whole thing wouldn't have happened, right? Like, the attackers compromises account using entirely factors that we were, that they refer to the security industry as things you know, right? Using his billing address, using his credit card numbers, using his password. And he says, had I had that second factor turned on, be something I have, these hackers who are an ocean of heart would not have had the ability to hack into my account. We have seen over the last year a ton of high-profile hacking incidents. And a lot of these, it's easy to look at a list like this and say, well, you know, I'm a developer, I don't really use Adobe or, I don't use LinkedIn, well, you probably do use LinkedIn. You know, and to go down the list, but we have one just the last couple of weeks to hit the developer community pretty hard, right? We had Slack.com compromised. And Slack.com compromised, they got full access to account credentials and hash passwords. So, you know, Slack doesn't store passwords in plain text, as you would think they would. But they did have a hacking incident. And what I found to be really interesting was the response that they had to announce the hackings. There's not even a column between security incident and we're launching two-factor authentication, right? Like, that is two-factor authentication is rapidly becoming the thing you do in order to prevent this from happening again. And so, there's a recent article in Slate, which is really interesting. You should give it a read. It says, every new software service should make strong security in from the start. And it goes on and talks a ton about two-factor authentication. It's basically what it's about. So, Google this will find me afterwards. I learned it's hungry in this article. And so, this brings us back to the Twilio and Authy combination, or, I don't know, trying to avoid using the corporate term like Twilio acquired an Authy, but I haven't quite figured out it with great questions. We joined forces, let's say. In the history of Twilio, we've always been kind of a, say, hammers and shovels company, right? Like, our goal has been to provide really strong tools to developers and then to let developers build the final solution. All right? So, we have not built a solution for, say, call tracking. We haven't built a solution for to build a call center. Our goal always has been to give you APIs and then to empower you to make it really easy to build the solutions that the rest of the world wants. The developers have always first and foremost been our customers. Authy is very similar in that their customers are first and foremost developers. But with Authy on our team now, this is the first time we've ever offered a foldable solution. And the reason for that is a ton of the people who are using Twilio. We're using our SMS for the purpose of two-factor authentication. But two-factor authentication, even if the SMS part is really easy to port it, can actually be very difficult to implement. You have to worry about things like randomly generating the pens in a way in which they cannot be predicted. You have to worry about things like, okay, we can send SMS, but what happens if you're in a building like this and maybe your user's not getting cell reception? What happens when your user travels to Europe and they don't have cell phone reception then? What happens when they lose their cell phone? How do you enable two-factor authentication across multiple devices, even if you're taking the phone out of the equation? So there's a lot of ways that you can get two-factor off the wrong. It's way more complicated than just sending a text message. You know, randomly generating a six-digit code and sending a text message. And so it's been really fun. Othi is a customer of ours, and so it's been awesome. Like, they are one of those developers who took our tools, built cool stuff on top of it, and went into power developers. And so it's been so fun watching them. They went through a wide combinator. One of their first customers was Cloudflare. Cloudflare had a very high-profile security incident in 2012, right as Othi's being started. The founder, Daniel, reached out to the Othi CEO. It was like, hey, you know, if you guys are interested in preventing this from happening again, I'm launching this thing. And so a two-factor off, and very much like Slack did, comes out at this experience and says, hey, we've been able to two-factor off. And since then, since 2012, Othi's just totally blown up. They're using out my over 2,000 websites and got over one million users. So that is to say the aggregate of all of those websites and all of those apps, the aggregate of all of their users are over a million folks now. And they're used by a whole bunch of people who, you know, names that you know in the development world. So CodeClimate, EchoFactors does private reports that you might not use them, but private reports are pretty important, Twitch and CoinBases, chargeifying CoinBases and other ones. And so I want to show you just what an end-to-end solution looks like on this because, and so I want to show you Coinbase here. And I want to log in. I'm going to do this using, how do you use a password manager? Okay. For those of you who don't, please, please, please do it. I started doing it about a year ago. It's kind of a pain in the ass to get started. But it really makes your life simple. Most people have free passwords, right? If you have your Gmail password, and then you have like maybe your meeting security password you use on all of my financial sites, and then you have that other password that everything else uses. And so if you, if you're a part of one of these sites, the site you can go to is, like, HaveMyBidAndOwn.com. And it's fantastic. You can look up and see if you've been compromised. And, like, I've had an DOE account that's compromised. Anyway, so Magic Coinbase. On Coinbase here, so I sign in, and then off he has, they deliver the SMS to my phone. And then they also have a Chrome extension that I can use. And so I can come in here to Coinbase, and I can basically use my laptop as one of the things that I don't have to inspire. So they're only good for, so now I was going to say, it looks like I'm assigning the codebase from a computer device that I haven't recognized before. So it's going to send me an email. And we'll check the email. And here we go. And we'll confirm this. And now it's back in. So is anyone here a Coinbase user? Is that over here? Okay. All right. I want to show you one last thing. After I show you this, I want to show you how to integrate Authy into your Rails app in about 15 or 20 minutes. So that you can implement features like what Coinbase does here. But this is super cool because I typically think of two-factor auth as something that you only do upon login. But what Coinbase has also done is enable two-factor auth on transactions as well. So what's your e-mail address? Or your Coinbase e-mail address? N-J-B-R-A-U-N. I'm going to send you 10% of all of the coins right now. Go ahead and send. And we'll send again. And because this recognized my device, there's actually, so I didn't do it here, but there's a setting you can turn on in your account that will only allow you to send other people bitcoins if you have the two-factor auth turned on. And I didn't turn that on by quality spur ahead of time. So before Coinbase implemented two-factor auth, people were losing bitcoins every single day. Like every single day somebody was having their account compromised. And they were getting parts of, if not all, of the bitcoins still on. And since they've implemented two-factor auth, they haven't lost any. There's like super powerful testimony. So if you have bitcoins out there anywhere, please turn on two-factor auth or else you will lose your, you will lose your bitcoins. All right. So now I want to show you how you go about integrating two-factor auth into your RSA. And to do this, I built just a super simple Rails app here. How many of you have, in the course of building Rails app, implemented your own authentication before? So it looks like about most of you. There's a fairly common issue that you run into pretty early in your Rails career. So there's a number of different ways you can do this. You can use a gem-like device that will give you, that will, especially if you're trying to do, say, like OAuth integration with Gmail or Twitter, Facebook. That works really well. For the purposes of this, I'm just going to, I kind of, I went through basically like simplest tutorial there is for building an app that takes the username and password inside someone's app. So I want to show you that. I'm going to show you the code that we used to do that. And then I'm going to show you what it looks like to insert coffee into a pre-existing app, which is how most folks these days are coming about working with two-pack Rails. So let me just show you how this works real quick. So I have, someone needs to sign up for an account. And alert sign up for an account. All you need to punch in is the username and the password register here. And then once you get it, you get access to the super sensitive data that I have, or baby pics of my five-month-old here. Which obviously is a hypothetical app because if you know anyone who has a baby, you know that there's nothing that people are more willing to give away than pictures of their babies. And so I'm here. I'm logged in. I can access my account. I can see all the cute baby pictures. Let's just make sure that you get a full view of all these. And then I'll sign out. And so let me show you just how that works real quick, the account creation piece. So you can see from my schema. Can you all see that okay? That's pretty good. So the schema is, the user model is really simple. So we just have an email and a password digest on here. So the password digest is a hash, password. So we're not storing passwords in plain text. And that makes use of Ruby's, Rails has your password here. And then we're just validating that the email actually fits the projects of an email. And when you create a new account, you know, most of the time in Rails, whenever you're taking input from a form, you have two different actions. You have one action that displays the form. And then you have one action that processes the data that comes from that form. So here the new is the one that displays the new user form. And then the create basically just takes the parameters, we're defining down here. It's the email password from the form. And then if it's able to save that user, okay, then it sets a session variable of user ID. And that's what everything, all of our authentication on this app is going to be based off of. If there is a session variable of user ID set, then we will give them access to the account, to the account page. And we can see here on the accounts controller that we're calling this method before filter authenticate. And that's just inherited from the application controller. Just right down here. This is authenticate. And basically this just says redirect to the new session path or the signup page. Or actually that's the login page. Anytime that unless you're signed in. And signed in is just looking at is there a current user and current user just basically says can I find a user in the database that's keyed off of a session, the user ID session variable set. So again, everything about this app is dependent upon. We're setting a session variable of user ID. And so if we were then to take a look at what happens when we sign in, this process is going to be really simple as well. All right, so we're just going to sign in. And I'm back into my account. And that was coming from the sessions controller right here. And I'm basically displaying the form. And then I'm grabbing a user. And then if the user is authenticated with the passwords, this is where Rails is checking. It basically takes the password I put through the form, runs it through the same algorithm that it used to generate the hash passwords that are being stored in the database. And if that works well, then it sets the session variable and it redirects to a different account. Otherwise, we just display an error message and we send them back to that page. And just to drag this home one more time when we click the sign out button, all we're doing is setting that session variable back to now. Okay. Does that make sense so far? Moral of the story, session periods. All right. Okay, so now let's take a look at how do we inject a second step into the sign-in process. So how do we take, how do we make it so that when somebody types in an email, and then when they type in their password, that they're going to get an SMS from offing. And they're going to have to punch in that code into our Rails app in order to have access to the page. So the first thing that I had to do is go to offing, sign up for a free account. If you, so what is it? I think an authentication is two cents and if you are under $3 in any given month, they don't send you a bill. So basically it is free for development. And unless you're running, once you get into production, you'll probably have a bill, you know, depending on what you're using it, but it's going to be pretty low. And so I need to grab my API key. And then my API key, I'm going to drop here into my secrets.yaml. Let's call this an offing key, or we'll call it offing API key. All right. And then I'm going to create a new file here on Kilmer Rails Server. And I'm going to create an initializer. And this is going to be offy.rb. And all I'm going to do here is set my offy API key equals to the secrets coming out of my secrets.yaml. So yeah, I'm not sure. Does anyone know what to talk to everyone about this? It's application. It's application. Application of secrets. All right. Trust me. Good. Thank you. If you all see a mistake, please feel free to correct. All right. And after we do this, we're going to include the offy gem. All right. And then we'll drop in the offy gem. And we'll just go ahead and I already installed the offy gem ahead of time just to save us some time. We'll go ahead and start up our server just to make sure that we don't get any errors, make sure that our initializer boots up fine. It looks like that's good. So in order to use the two-factor off, we're going to need to collect the user's phone number. And we're also going to need to add an offy ID to their account. So we're going to create a new migration to add the offy information to where you use it. We're going to need to add three columns out here. So to our user's account, or to our user's model, we're going to add an offy ID. So this is going to be an ID that we get back from offy to scope to our application to uniquely identify the user. We're going to add a phone number. And we're going to add a country code. Now, we want to make sure that we are accommodating to international users. And so, you know, US numbers are prefixed by one, but not all US number, not all phone numbers in the world are prefixed by one. Now, we're going to do this here. We're just going to make the user type it into the form. Offy has some really sweet JavaScript to help with the selection of the country code and whatnot, but it's going to be a little ugly for our purposes. All right. So let's just run our migration. So we added our three columns here. And now let's, we'll change our view in order to accommodate to add the field. So this gives us a little one of those spots that whenever I'm doing these live demos, I'm always met with input, right? So yeah, this is a little, do you show a super ugly form to your audience? Or are you input bootstrap and show super ugly review code of CSS styles? I've opted for the latter. I am totally open to suggestions. You're going to find me afterwards and let me know as an audience member which way you work. So, but basically this guy is mostly CSS. The real crux of it is we're generating a form and then we have two fields. This is what you saw when we created a new user, one for email, one for password. So I'll just copy this here. And we're going to replace both of these. So instead of a password, we're going to do, this will be a country code. And instead of a password field here, there's just going to be a text field. And that's going to be, oh boy. Thank you. Country code. And then down here, there's going to be our phone number. There's going to be a text field again. All right. Sound good so far? Yeah, all right, cool. Let's just take a look. So this is going to be user's controller. This is what's, again, displaying the form. This is what's creating the form. There's going to be some stuff we're going to need to change here when we create a new account. But let's just take a look real quick and just make sure that form's displaying properly and that everything turned out well. This might be a little trick for most of my development. I display the console and the view so that I can do stuff like this as I'm actually doing development. That makes sense. All right, so let's do this. All right, so we just deleted the user that I do have. So when I come in here, I'm going to register and we can see here that we have my form. And I'm collecting a country code and a phone number, right? So we're going to do a couple of things here. Previously, we were solely saving that information to our local database. Now we need to create a new user and off. All right, so we'll do that here. If the user is saved properly in our local machine, then we will use the offy gem and we'll call this method called register user. In order to register a user, we need to pass in three bits of information. Any idea what those bits of information are? Instead of ID, we'll use the email. You're absolutely right. That is perfectly our ID here. And then you're right. You said country code, right? So now we are creating a new user and when we do that, off is going to return just a hash that has the ID of, like the off ID of the user. And so assuming we get that back, we're going to then update the user and we'll save that off the ID that came back. All right. So let's run this again. Let's refresh this and I'll now sign up for an account again. Oh, you're so smart. Thank you so much. Thank you. All right. Look good. All right. So country code, type in my super secret password, which is password, and I'll register for an account. And there we go. So, and just to make sure that that worked right, we can look in here and we can see that we do in fact have an off the ID. So that means we were able to successfully hit the, you know, off the API and then we are then able to create a user here. And this actually I think was here from previously. But you can look down here and see that we have, so if a user is trying to re-register, they'll just give you back the same ID that you're getting. But you can see it shows up here right now. All right. So we have successfully registered a user with off the, and for this use case, you know, often I think the best path is when somebody creates an account, you typically are just signed directly into your account, right? Like it's very rare to go through this, go through the path where you create a new account and then you're forced to sign in immediately afterwards. It's kind of jarring. So I think we're good to go here as far as what happens when we create a new account. What we want to look at next is what happens when the user signs out and then they come back to your site again. All right. So that's going to happen in our session to controller, which controls all of our sessions that are signing in and out. And I'll just come over here and I'm going to sign out. We're going to need to create two more actions here. And so just as we have two actions in order to display the initial sign up form, you know, the new and the created, we're going to create two more actions. One of the words is called two factor. And the other one we'll call verify. And we're going to need to create routes for those sessions to factor. And we'll do a post for our sessions verify. All right. And we're going to this part right here where we are creating our session and we set that user ID session variable and we redirected the account path. That part, we're going to move into the verify. I'm going to comment it out for right now, but we're going to come back to it because we're basically moving that final authorization into something that happens after they verify their pen. Okay. Instead of setting that final user ID, I'm just going to set up what I'm called pre to a VA ID. And we'll set that to user ID. So now they make it to this step, even though that pre to a VA ID is set, the user ID is not set, so they won't be able to access the account page. And the next thing I do is so this is what happens when I click the sign in form, right? Because I need to tell AFI to send them an SMS with a pen code. So I'll say here AFI API, I'm going to request an SMS. And all I need to do then is send them the AFI ID, the stored in the, the stored in the database there. And then I'm going to redirect them to the two factor path. Actually this is a session. You know what? I thought so too when I was doing this and AFI, their API is looking for ID, even though it's stored as AFI ID on our site. No, and your user option. Oh, thank you. Yes, instead of AFI. Thank you very much. Nice change. All right. So we're redirecting the session's two factor path. So let's create a form to have someone punch in a code for us. All right? So we'll come in here to have and we'll drop into our views for our sessions and we'll just use that view form as a template. And we'll do the same thing on top. So I was displaying error messages here if they did not sign in properly. So we'll just call this here verification code. We'll just call it verify. And we'll display a warning if it shows up. Instead of having this form direct to the sessions path, we're going to have this direct to the sessions verify path. All right? So when they click this emit button, it's going to take them to the verify action on our sessions controller. So instead of doing an email here, we're going to just call this code. We don't need to display anything in that field when they first come to it. There's no default out here. All right. So let's do a text field and then we'll delete that second field. We don't need that. And instead of telling them that we're going to sign in, we're going to tell them to verify. And you know what, instead of code, it really doesn't matter. But I'm just going to call this token just to use the same terminology on the back end. It's not what the user sees. Typically, users think of these things as codes off of your version of this token. It just keeps consistent in the next code here. Label tag code. Oh, you know what? I leave it as code. This is confusing. I almost just kept all the code. I leave it code for purpose just for the sake of consistency. All right. So, and then we do not need this bit here. All right. How do we look? It's making sense so far. All right. So our moment is true here. Things start up, so that's exciting. So now I'm going to sign in. Let's just make sure. So we still have, you still see users still in the database, right? We have our ID in everything. So I want to sign in. All right. So it comes up. It says verify your code. And I just got a text message here with my RailsConf secure code. All right. Now, if I type this code in here, nothing's going to happen just yet because we haven't actually implemented that so far. But we're able to successfully send a code here. And this is kind of the cool thing about Office. So if I were to lose my cell phone, I could still use my computer as something I own. With the offie app. All right. So if I come up here, I can see my RailsConf pen. And so I don't actually need my cell phone here. I can actually just copy this from here and paste it right in to the form as well. So this allows you multiple things you own. And it makes a little convenient so that you're not having to manually punch in these codes. So we're able to get a code. Now let's have the user be able to punch that code back in and verify that that works. We already covered this. This is what displays our form. So now we need to, on the verify side, so when you actually enter the code and hit the button, we're going to first grab a user from just in the same way that we've done above. Oh, okay. So the user's already signed it, right? So user.fine. And we're going to look at the session ID of our creating 2FA. All right. So that's just the same one that we set up here. So that stayed there stored as a session variable as we've gone to that next page. All right. And so then if we have a user, we're going to do something. And that we'll do. So first we want to get a verification. So in order to get the verification, we're going to have to hit offie's API again. And we're going to run a verify. And we're going to have to send offie two things. Any of you know what those two things are? Exactly. User offie ID and the token. And the token's being passed in the prams. Okay, like that. Makes sense? And then if the verification goes okay, then we're going to do the same thing that we had done here before. And we're going to set the user ID. And we're going to redirect to the account path. Otherwise, we'll do roughly the same thing that we had done when they didn't log in correctly, which is set a message. And we'll redirect them back to the 2FA. Does that make sense? So this is very closely mirroring what our, what our creative method was doing before. All right. So here's our moment of truth. So let's try this out again. We'll come back. And try the authorization process again. And punch in my password. Wait for my phone to blow up. All right. So I got, punching my code, zero, nine, two, six, seven, six, zero. Undefine, oh, you know what I think this is. Oh, missing template. Sessions, oh. Sessions, two factor. Your render is wrong. I'm sorry. Say that again. It should just be render two factor. Oh, right. Okay. Oh, just render two factor, not two factor. You're absolutely right. Thank you. All right. So that was our, so basically I need to re-verify here. So we'll get my token again. We have three, zero, nine, nine, seven, one, nine. All right. And now we have my baby kicks again. And just so you can see what the SAT path looks like properly. If we punch in the wrong code, we do not fit the baby kicks. Okay. So that's it. So that's, I don't know, about 15, 20 minutes or so. And we're able to integrate two factor authentication into a real-time that has pre-existing authentication. So my hope is from this talk, to encourage you to do two things. One, forget the factory developer as a consumer or someone who uses the internet. Enable two factor on absolutely everything that you want. It could save your life. I don't know, that's probably hard for me. But it's just, we're seeing the incidents there's growing in an exponential way. And two factor off will remain so many of the attack factors that will allow hackers across the globe in order to get into your account. And two, if you are, you know, as a developer, I would strongly encourage you to implement two factor off using some method, preferably off, but implement two factor off into your own account. It's the responsible thing to do for your users. And if you compare it against the liability of either A, say like losses, or B, because the time and energy associated PR costs associated with a hack or dealing with upset users is a no-brainer investment, especially if you can do something like this and, you know, let's just call it a day of working with a production app. So that's it. I'm up here. If you have any questions, let me know. But thank you very much.