WEBVTT 00:00.000 --> 00:12.080 I'm here to talk about a secure and inclusive alternative for multi-factor authentication. 00:12.080 --> 00:13.920 It's called WeboutN. 00:13.920 --> 00:17.680 But first, maybe a little bit more about me. 00:17.680 --> 00:18.920 I'm Stormack. 00:18.920 --> 00:20.880 My pronouns are here in aim. 00:20.880 --> 00:23.560 I help from the Netherlands. 00:23.560 --> 00:28.760 In my day job, I'm an independent contractor and I build websites with spectral CMS in 00:28.760 --> 00:29.760 Django. 00:29.760 --> 00:33.400 And I do that since 2019. 00:33.400 --> 00:34.400 I love open source. 00:34.400 --> 00:37.640 I'm a member of the Black and CMS Core Team. 00:37.640 --> 00:42.200 Most people here, I'm organized from the room are as well. 00:42.200 --> 00:47.600 I'm also an admin for the Django Comments Initiative, which is some initiative to help 00:47.600 --> 00:53.880 facilitate maintenance of packages that extend Django in some way. 00:53.880 --> 01:03.720 And I also create open source of my own search as Django OTP WeboutN more about that later. 01:03.720 --> 01:09.240 So quickly, briefly, what I'm going to talk about, a multi-factor authentication-wise 01:09.240 --> 01:15.640 importance, security first, usability trade-offs, come to introduce WeboutN and then how 01:15.640 --> 01:19.920 can you use it yourself. 01:19.920 --> 01:23.560 So first, let's take a step back. 01:24.040 --> 01:24.880 Passwords. 01:24.880 --> 01:28.840 We all know passwords, but they have some shortcomings. 01:28.840 --> 01:31.040 They're not enough. 01:31.040 --> 01:33.960 For one, they are hard to remember. 01:33.960 --> 01:40.200 That's why people choose welcome 1, 2, 3, exclamation mark as their passwords. 01:40.200 --> 01:44.480 They're preyed on by fishing attacks. 01:44.480 --> 01:52.040 So criminals, they try to convince your user to enter their password to your surface 01:52.040 --> 01:57.320 on their fishing websites and yeah, then you have a problem. 01:57.320 --> 02:02.400 And one other thing, when it password is that they are commonly reused across websites. 02:02.400 --> 02:06.120 So a user has used the same password on multiple websites. 02:06.120 --> 02:13.000 If they're password leaks, then certainly criminals can try to use this password on your 02:13.000 --> 02:14.000 surface as well. 02:14.000 --> 02:18.280 See, hey, maybe I can log in here. 02:19.240 --> 02:22.000 Yes, password managers exist. 02:22.000 --> 02:29.600 They do solve a lot of problems, but not everyone use them or knows how to use them. 02:29.600 --> 02:35.800 And with multi-factor authentication, we are trying to add another layer of security. 02:35.800 --> 02:41.640 So typically, that's something you know, like a password, something you have, like a phone 02:41.720 --> 02:50.360 or security key, or your access to your email account to receive the email there, or sometimes 02:50.360 --> 02:56.760 something you are like biometrics. 02:56.760 --> 03:05.840 Now, as this effort happened to you, you are waiting for an email to arrive with a code 03:05.840 --> 03:06.840 to log in. 03:07.080 --> 03:11.520 And another writing, raise your hand, has this habit to you? 03:11.520 --> 03:15.120 I see a lot of hands. 03:15.120 --> 03:20.000 You need an SMS code, raise your phone as no reception. 03:20.000 --> 03:23.640 True story. 03:23.640 --> 03:27.640 Or even worse, you switched phone numbers, and now you can't log in, because you didn't update 03:27.640 --> 03:33.280 your number at all, so I'm sure you'll never use. 03:33.360 --> 03:34.160 An eye, right? 03:34.160 --> 03:38.360 It's inconvenience to wait for something to arrive, or to take out your phone, to approve 03:38.360 --> 03:41.200 a log in. 03:41.200 --> 03:44.000 But we all do this in the name of security, right? 03:47.760 --> 03:54.160 OK, it's inconvenient, but we solved security problem, right? 03:54.160 --> 03:56.000 Sort of. 03:56.000 --> 04:00.000 We made it a bit harder for an attacker, but pushing is still a thing. 04:00.000 --> 04:06.440 You can still enter an SMS code you receive, or convince someone that receives an 04:06.440 --> 04:10.720 SMS code to enter it on your fishing website. 04:10.720 --> 04:12.840 It's just a little bit more difficult. 04:16.400 --> 04:20.240 Also, it's not very intuitive for everyone to use. 04:20.240 --> 04:24.480 OK, so I'm trying to look in here, but now I have to do something with my phone. 04:24.480 --> 04:32.800 And what this creates friction to your surface for your users. 04:32.800 --> 04:36.120 And I don't think that's very inclusive. 04:36.120 --> 04:42.800 Not everyone is like well aware of how this work and why 04:42.800 --> 04:46.440 a multi-factor authentication is important. 04:46.440 --> 04:50.320 So it isn't there a better way to do this. 04:50.800 --> 04:53.800 There is. 04:53.800 --> 04:58.480 Otherwise, there wouldn't be standing here, if I didn't leave it to us a better way. 04:58.480 --> 05:03.360 Many of you have heard of it already, in the name Palskis. 05:03.360 --> 05:10.720 But the more official standard behind this is called WeboutN, or short-for-web authentication. 05:10.720 --> 05:16.440 It's a standard for secure Palsworthless authentication. 05:16.480 --> 05:19.640 It's based on a public key cryptography. 05:19.640 --> 05:23.160 So there are no shared secrets like with a Palskworth. 05:23.160 --> 05:26.400 Most media browsers support it. 05:26.400 --> 05:32.200 It's around since 2020 or so in the form I'm describing here, but still relatively 05:32.200 --> 05:34.000 a known I think. 05:34.000 --> 05:35.240 But it's gain in traction. 05:35.240 --> 05:41.040 Mostly due to Apple, they made a big thing out of this with the launch of their iOS 16 operating 05:41.040 --> 05:42.040 system. 05:42.280 --> 05:51.120 Now what I think is really great about this API is that the prompts to log in or to create 05:51.120 --> 05:53.880 an credential are very predictable. 05:53.880 --> 05:55.240 They are native. 05:55.240 --> 06:03.880 This is the prompt from Safari on MacOS and it's asking me, hey, do I want to use my fingerprint 06:03.880 --> 06:08.560 to sign in under my account storm hack at GitHub. 06:08.560 --> 06:15.440 And I think this is the future of authentication. 06:15.440 --> 06:23.680 So quick overview of how this works because maybe it's all magic to you now. 06:23.680 --> 06:32.240 When we want to register a new Palskis, a new credential, we ask the browser to do this. 06:32.240 --> 06:38.840 So this is about API, navigate.quadentures.create. 06:38.840 --> 06:43.880 And we ask the browser, hey, please create a public private key pair. 06:43.880 --> 06:48.720 The private key is stored securely on your device of the user. 06:48.720 --> 06:58.160 And the public key is sent off to your server with a reference, a new server, you store 06:58.160 --> 07:10.360 this public key with a reference to which user is this bit like an SH key maybe. 07:10.360 --> 07:16.080 And this public private key pair is informally called a Palskis, roughly definition of 07:16.080 --> 07:17.080 Palskis. 07:17.080 --> 07:23.360 I find it a bit fake, but I think it refers to the public private key pair or more generally 07:23.360 --> 07:28.400 this whole mechanism of authentication. 07:28.400 --> 07:37.200 Now when I use it once to log in, we again, we ask the browser like, hey, sign a challenge 07:37.200 --> 07:39.880 with the private key that's stored on your device. 07:39.880 --> 07:47.560 So this, when we call this API, navigate.create.create.get in the browser, browser prompts 07:47.560 --> 07:50.360 to use it like, hey, this side is asking you to log in. 07:50.360 --> 08:00.240 I have these key stores available, which account do you want to use. 08:00.240 --> 08:05.960 The browser then signs a challenge, we sense. 08:05.960 --> 08:12.440 And with that sign challenge, we can verify the signature is correct with the public key. 08:12.440 --> 08:18.480 We have, okay, this signature was created with the private key that belongs to this 08:18.480 --> 08:19.480 public key. 08:19.480 --> 08:25.640 You must be in possession of the private key and so you must be who you say you are. 08:25.640 --> 08:32.520 And if that's the case, well, then we can lock you in because we know which user is associated 08:32.520 --> 08:40.880 with that public key and no password is necessary. 08:40.880 --> 08:42.560 That's immediately the first benefit. 08:42.560 --> 08:48.200 There's nothing to remember, no shared secrets, another thing is there is a new key pair 08:48.200 --> 08:50.320 for every site. 08:50.320 --> 08:55.280 So it's not possible to reuse like with a password. 08:55.280 --> 08:57.640 Every key pair is unique. 08:57.640 --> 09:05.240 So it does not matter if that side has a database, then yeah, that does not affect any of 09:05.240 --> 09:08.640 the other sites that you might be using, a passkeys with. 09:09.400 --> 09:15.400 Another benefit is that you can register separate passkeys from multiple devices. 09:15.400 --> 09:24.560 So you have to use the same password all the time or with your account because you can't 09:24.560 --> 09:26.880 have multiple passports for your account. 09:26.880 --> 09:30.840 With the passkeys, you can register multiple passkeys to your account. 09:30.840 --> 09:36.600 So if I register a passkey on my phone, I can use that to lock in or on my laptop, I can 09:36.600 --> 09:39.440 use that to lock in. 09:39.440 --> 09:41.240 I think that's a benefit as well. 09:41.240 --> 09:46.000 So if I lose one device, I have a passkey stored on another. 09:46.000 --> 09:50.400 There also a fishing assistant, the only work on the site they were registered on because 09:50.400 --> 09:58.520 the browser says, well, I don't know Google.com. 09:58.520 --> 10:04.880 Whatever type of squatting a fishing site did, it just does match the site, I have a passkey 10:04.920 --> 10:10.560 stored for so you have no passkeys, you can use here. 10:10.560 --> 10:17.960 Passkeys, you can also see them as being multifaceted because the passkey, the private 10:17.960 --> 10:24.160 key is something you have and still protect it by metrics, something you are or your 10:24.160 --> 10:26.960 device, pin or password, something you know. 10:26.960 --> 10:33.260 So your device that is stored to the passkey, typically ask you like, hey, you need to 10:33.300 --> 10:37.380 confirm who you are, before I will actually assign this challenge. 10:37.380 --> 10:42.700 That's what you saw on the previous slide, it asked for my fingerprints, but can also 10:42.700 --> 10:49.220 be the pin of your device or your password of your laptop and that's something we get 10:49.220 --> 10:59.020 to see as a server, it's just necessary for the browser to unlock and assign this challenge. 10:59.020 --> 11:06.020 That's an additional factor, so yeah. 11:06.020 --> 11:12.380 I'd say there's also a couple of drawbacks or maybe things that passkeys don't solve, 11:12.380 --> 11:15.020 not technically, she's perfect. 11:15.020 --> 11:21.700 Yeah, losing your passkey is still a risk, I mean if you passkey register on my laptop, 11:21.740 --> 11:29.340 my laptop breaks and my phone is stolen and yeah, my my my passkeys are gone. 11:29.340 --> 11:36.020 The solution to this could be a cloud sink, but that could also be a risk because, for 11:36.020 --> 11:43.940 example, Apple, it stores all your passkeys on the iCloud key chain, so your Apple 11:43.940 --> 11:49.340 accounts or whatever big tech accounts you're using to sink these passkeys with, then 11:49.380 --> 11:54.780 I was seeing a point of failure, but so what's your password manager already, so I don't 11:54.780 --> 12:01.980 think we are taking a step back in that regard, quick side notes, most password managers 12:01.980 --> 12:08.660 can also do wrap out and so you can use your password manager instead of your Apple account 12:08.660 --> 12:15.540 or whatever, I think that's a pretty cool feature. 12:15.540 --> 12:21.980 So what do you need to implement web authentication on your platform website? 12:21.980 --> 12:29.820 Well, I'd say it's quite involves, I made a quick rough overview, I'll have a overview 12:29.820 --> 12:36.060 checklist on the server side, well you need API and points for the registration and 12:36.060 --> 12:41.020 authentication ceremonies because it's not just one API call you need to make your 12:41.020 --> 12:50.100 server it's always to want to start and want to complete the process, so you can 12:50.100 --> 12:55.580 integrate those API endpoints, you need some database mechanism or something to store 12:55.580 --> 13:02.260 the public key if the pass key, you need to verify the signature of the passkeys, so there's 13:02.260 --> 13:07.620 some cryptography involved on the client side, well we need to communicate with your 13:07.620 --> 13:14.380 server, make the appropriate browser API calls and handle any exceptions that may arise, 13:14.380 --> 13:21.700 but it can happen, no passkeys are available, maybe there's a configuration error, a lot 13:21.700 --> 13:27.700 of things can happen and well ideally you should show some sort of actionable feedback to 13:27.700 --> 13:34.100 the user, web authentication also has some additional features like a pass key out of 13:34.100 --> 13:39.060 a file and to use this you need to call the browser API slightly differently, without 13:39.060 --> 13:47.220 a file I mean when you land on a login page or for websites then sometimes your browser 13:47.220 --> 13:54.580 shows you like an out of a file request like your password manager might do and this is also 13:54.580 --> 14:01.260 like triggered by that website like hey if this this has passkeys show a prompt now 14:01.260 --> 14:10.500 and also on your website well you need an area to manage the passkeys, okay I have these 14:10.500 --> 14:16.500 passkeys registered to my user account, you need some interface on your site to manage 14:16.500 --> 14:28.260 this and general you need to spend quite some effort to make it a smooth experience. 14:28.260 --> 14:35.260 Well I took a look at the open source options there are to make this a bit easier, I know 14:35.260 --> 14:39.260 not everyone here is using Django so I included some other frameworks here as well don't 14:39.260 --> 14:49.540 know anything about them first results on Google don't trust me, yeah let's lots of libraries 14:49.540 --> 14:58.540 that make this easier for you to implement quick shout out to myself I'm the offer of Django 14:58.540 --> 15:10.220 OTP WebRFN which is a library I created to integrate WebRFN with a second factor authentication 15:10.220 --> 15:16.260 because I'm not quite ready to go full passwordless for all my clients and websites but it would 15:16.260 --> 15:22.260 be nice that if I have to implement no defect of authentication I can do it with like offering 15:22.260 --> 15:41.700 a print scan yeah this is it thank you and any questions yeah so the issue that I'm 15:41.700 --> 15:49.540 seeing currently with passkeys is that as server or as application people we cannot enforce 15:49.540 --> 15:55.540 second factor and because usually it's done on the device yes anything like security 15:55.540 --> 16:01.420 levels that I can raise so it needs to have second factor on the game yes that this is something 16:01.420 --> 16:07.740 I didn't include in my presentation for BFT but there's like a lot of mobs in the API you 16:07.740 --> 16:15.060 can tweak like hey this device needs to be capable of user verification that's what WebRFN calls 16:15.060 --> 16:21.300 it there must be some the authenticated device that stores the passkeys needs to have some 16:21.300 --> 16:28.100 mechanism to verify the identity of the user using it but yeah you're right we're trusting 16:28.100 --> 16:36.020 the interesting this device with this responsibility to do so there's also a more enterprise 16:36.180 --> 16:42.020 way of enforcing this that I don't think I would recommend but passkeys they also have 16:42.020 --> 16:49.300 something called at a station where you can verify that the device that created this passkeys 16:49.300 --> 16:55.300 of like a certain make so it's for example it's the Apple implementation of passkeys because 16:55.300 --> 17:05.700 we know Apple implement this well I'm naming Apple as an example yeah you can enforce this 17:05.860 --> 17:13.300 but I wouldn't do so because it's quite a lot of work and the landscape changes all the 17:13.300 --> 17:19.460 times so you need to keep up or rush your risk cutting people out and that's nothing 17:19.460 --> 17:33.780 inclusive so I get that when you register an account you also create the first passkeys and 17:33.780 --> 17:42.580 the Apple slogan is a whole time to let device but how do you see the next device you want to 17:42.580 --> 17:51.860 change it's about into that well yeah technically you could you could implement it in a way 17:51.860 --> 17:57.860 without passkeys at all I currently the way I'm doing it and complimenting passkeys 17:57.860 --> 18:03.220 passkeys are still a thing for my websites but yeah I can see we're going full pass with 18:03.860 --> 18:13.300 in the future one way back off and dust this and there's not something I show you either because 18:13.300 --> 18:21.060 I only have 20 minutes but when you're logging in or you're seeing this prompt to log in you can 18:21.060 --> 18:28.580 also choose to use a passkeys from a different device what happens is your computer you're 18:28.580 --> 18:34.180 logging into will display a QR code and if I have a passkeys stored on my phone for example 18:34.180 --> 18:42.580 I can scan that QR code and then this device and my phone will connect and 18:43.860 --> 18:49.380 like your request to sign a challenge is pass on to my phone and my phone sends the sign 18:49.380 --> 18:57.700 challenge spec to the computer so that's one way you could log in with that authentication 18:57.700 --> 19:03.140 like on a public computer for example and it's pretty cool because that public computer never gets 19:03.140 --> 19:17.460 to see your private key yeah exactly well 19:18.100 --> 19:24.100 when I take a look at large vendors they usually forcing us into their app ecosystem right 19:24.100 --> 19:31.220 and you still have lock-ins and services is there any app like implementation for 19:31.220 --> 19:39.300 for passkeys so I can sign in with my passkeys by earlier well like I said pass with managers 19:39.300 --> 19:46.180 pass pass managers they can do a passkeys authentication because they intercept the 19:47.300 --> 19:54.900 the API calls to the browser to inject their own implementation yeah I think they are like 19:54.900 --> 20:03.460 then 20 implementation out there already to either through pass managers or other 20:03.780 --> 20:11.780 systems yeah you're not you're not locked into like the Apple way if doing it or the Google way 20:11.780 --> 20:18.260 of doing it you can store your passkeys in a pass manager as well yeah I was I was rather thinking 20:18.260 --> 20:25.060 instead of using a browser to lock it into Apple.com I want to do it with my settings app on my 20:25.060 --> 20:31.300 iPhone then how do I do the login right because usually anything that you've said is like browser 20:31.620 --> 20:38.900 well I assume the settings app would have to implement something similar to the browser 20:38.900 --> 20:46.180 to make this work but that's not my area of expertise sorry 20:49.220 --> 20:54.660 yeah as when I see applications that I don't have a one-of-reindance 20:54.660 --> 20:57.940 the way because I'm not an expert I just want to reuse something that's not there 20:58.260 --> 21:04.100 and you show that's three different channel recommendations on your list so should we wait 21:04.100 --> 21:09.460 to have a bomb or stay home and there's one go to wait and do it for your system or is it like 21:09.460 --> 21:15.780 okay it's security now for you know risks are low enough that's good right now 21:15.780 --> 21:24.020 well my version is still like in alpha so I wouldn't recommend you go to production 21:24.660 --> 21:28.340 maybe maybe later like the while long ago to foster in twenty twenty six 21:35.460 --> 21:37.780 okay one more question and I think we're done 21:37.780 --> 21:44.180 I'd like to ask you a question before about this another device what happens if I have 21:44.340 --> 21:51.460 only one device I lose control of it I get stolen and that's the only way I add 21:51.460 --> 21:58.820 or three three my private properties yeah that's like one of the drawbacks I mentioned 22:00.020 --> 22:06.820 I assume there would be some recovery mechanism like we have like forget your path now 22:06.900 --> 22:16.420 it would be forgot or lost your passkeys so I think it would involve like sending some sort of 22:16.420 --> 22:24.660 recovery link to your mailbox maybe there is still another contact information for the user 22:24.660 --> 22:29.860 well yeah it's it's up to the implemented to like have a recovery mechanism 22:29.860 --> 22:41.620 thanks for a few more questions if you have a three more minutes on the top 22:44.180 --> 22:49.780 no you mentioned you would recommend that the station is that you mentioned what I mean 22:49.780 --> 22:52.740 the problem was the implementation time basically I'm keeping up with the 22:53.220 --> 22:59.460 case of things that are open so it's not a technical comment like we should go without 22:59.460 --> 23:03.940 the station just make sure you have enough time to keep up with everything that happens to be 23:05.940 --> 23:13.620 well I I say because for example right now there's one at the station met at the 23:13.620 --> 23:19.620 developed by Google but they've already deprecated it and it's going away so that's that's 23:19.620 --> 23:24.260 what I what I mean don't use at the station unless you want to keep on top of what the 23:25.380 --> 23:32.180 implement of at the station are doing I like five different at the station formats that you would 23:32.180 --> 23:39.220 want to support because if you're asking for at the station it can only go in the way it can only 23:40.100 --> 23:47.220 and I've dedicated to can only do it in the way it's implemented to so if only supports the 23:48.020 --> 23:56.260 Apple way of stepping out at the stations then you need to do it Apple way or yeah 23:58.180 --> 24:00.340 that's not something I would like a minute 24:01.300 --> 24:06.820 and the best of you just think you wouldn't you wouldn't recommend doing it yourself but what about 24:06.820 --> 24:14.740 that using a service like private people for authentication? Well if that means that you do all the 24:14.740 --> 24:19.620 responsibilities of keeping up to date with at-stage from you you leave that up to another party 24:19.620 --> 24:27.060 then yeah sure but if you're all doing it yourself you have your own implementation of Apple 24:27.060 --> 24:39.060 and no don't please so one more hand is raised running more are there any public sector 24:39.060 --> 24:51.220 websites like go UK or things like that using baskets? Well I can't speak for coffee UK I know the 24:51.300 --> 24:58.740 Dutch government do not use a ball ski shed but I know that's for example on your WhatsApp 24:58.740 --> 25:06.500 now supports logging in with ball skis with data you can log in with ball skis Amazon 25:07.620 --> 25:12.340 Amazon even like offers you like if you're checking out at a product and you don't have a 25:12.340 --> 25:18.020 ball ski yet it says like hey do you want to create a ball ski for easy checkout next time 25:18.020 --> 25:24.420 so public sectors maybe maybe not so much yet but a lot of other organizations they do already