[MUSIC]
 [MUSIC]
 So our next speaker wants to make passwords redundant and
 will tell us a little bit about Fido 2.
 So please welcome Cy with Fido 2,
 the superior multi-factor authentication framework.
 >> [APPLAUSE]
 >> Did someone boo?
 Okay, all right.
 Yeah, I wanna talk about Fido, but I will use the word WebAuthn,
 probably even more, I will explain why in a second.
 My name is Chris, I'm a software developer from Germany.
 I am a little interested in security and DevOps stuff and automation.
 I have worked system administration before all that new modern DevOps stuff came up.
 I do organize a meetup about this stuff also in southern Germany in Karlsruhe.
 And I am a little into Millieways orgo.
 So if I have screamed at you for standing in the way in the kitchen,
 I'm very sorry.
 All right, so I have put together a small agenda for today.
 I will talk about what Fido 2 or in specific WebAuthn is,
 like explain how it works and why you wanna use it.
 And why you probably should use it over the alternatives.
 But I'm open for discussion afterwards.
 How does it work?
 And then I will talk specifically about pass keys,
 because this is coming like a new hype, I think, for security.
 And it might be really cool for a lot of people, but
 it might be slightly almost cool for some people sitting in here.
 We'll see how that goes.
 So what is Fido?
 And I think I wrote something next to it actually.
 Yeah, I copied the slides.
 Good job.
 So there is two parts to Fido.
 And the most interesting part is WebAuthn, which is a W3C standard.
 And then there's the Fido 2, which is actually a brand.
 But most people use those names like and swap it out.
 Fido 2 is a brand by the Fido Alliance and
 a lot of the big Internet companies like Amazon, Google, also One Password.
 And a lot of security companies are part of the Alliance and
 they set the standard and work on stuff like WebAuthn.
 They're also pushing, most of those are also the ones pushing for pass keys.
 Which is, yeah, it's okay, I guess.
 And I think the Internet overall is gonna profit a lot from this from
 a security perspective.
 And yeah, I'll go to this a little later.
 I will show you just for a second how this works, WebAuthn.
 So I have, when I prepared this, I have found a website.
 This one is, I think it's from Duo Security, if some of you know this.
 It's WebAuthn.io, but there's multiple listed on the Fido Alliance and
 the WebAuthn pages, you can Google those.
 This one here I found very good to get a general understanding how this works.
 Because you can just play around with it.
 Let's say I will register a new account here.
 And let's say this is called CyCCCcamp.
 And then there's a couple of settings to need to hit.
 I'll just, I forgot to turn this, no, wrong one.
 I just forgot to turn this one off now, but we'll get to it later.
 So you press Register, you can create a passkey, and this is like a spoiler.
 Because passkey is basically a wrapper around WebAuthn.
 And you can choose a security key.
 This device, so this is a MacBook, standard MacBook, nothing fancy.
 Security key would be something like a YubiKey, I'm using a NitroKey here.
 YubiKey is I think the most well known producer and
 a big part of the Fido Alliance also.
 Probably all of you have seen YubiKey at work.
 NitroKey is a company from Germany which does a lot of open source work.
 I just want to give them a little shout out.
 They sponsored a NitroKey for me.
 But it's up to you, it's the same thing.
 It's a USB key that you can put to your key chain and carry it around next to you.
 And hopefully not next to your laptop in your bag.
 All right, let's lose and use a security key and now I have to touch it.
 And something went wrong, that's cute.
 Whoops, yeah, probably time out.
 So you have a couple of seconds to use the YubiKey or
 Fido NitroKey, whatever key.
 So now the server has, I'll explain a little later.
 But what we have essentially done is we have created a public key or
 private public key pair and we have sent the public key of this to the server.
 And now when I go to webauthent.io and I will do this in a private tab.
 Just to make sure the sessions don't interfere, it should work out of the box.
 And we said, si ccc camp.
 And now I can authenticate.
 No, that's good.
 >> One more thing.
 >> One more thing, why?
 Yeah, good catch, thank you.
 All right, so authenticate.
 Now this thing, the site knows that I have set a passkey for this username.
 So it queries me to use my passkey.
 So I use the security key, there's multiple additional versions.
 I touch the key and now it says I'm logged in.
 And then it shows the credentials that I have here.
 There's like, this is just an ID.
 If you want, you can take note of this.
 And you cannot hack my webauthent.io account later with it.
 Doesn't matter anyway because they will delete the account tomorrow.
 All right, but you get a lot of webauthent.io, webauthent.guide,
 I think is the big one from the Fido Alliance.
 They have a lot of resources if you want to learn more in depth stuff about this.
 All right, so basically this was already an example where you don't use a password.
 So this is basically, you give them your username.
 They know who you are.
 They can map your pub key that you have saved there while registering.
 And then you can authenticate with it later multiple times, obviously,
 every time you want to log in.
 All right.
 Yes, okay, so what is it actually?
 And this is from the definition of webauthent, the webauthent framework.
 It says, this is a better alternative for securing your sensitive information online.
 And the webauthent works for
 like for an alternative authentication factor in addition to your password.
 But it also works without.
 And it will still be multi-factor authentication if you don't use a password.
 And I will show you in a second how that works or why this works.
 So there's a kind of factors that you can use for multi-factor authentication.
 Some of these might be the alternative to webauthent.
 So this, on the left side I put, is it on the left?
 Yeah, on the left side I put a lot of keys.
 There's multiple brands in addition to Ubiquity and Nitrokey.
 There's also Titankey.
 I think Google uses this, or it used to do, and
 they have some blogs on how to implement this.
 And I did some screenshots from Chrome just because it's like the most,
 I'm no advertising, okay?
 So you can use a password to log in as a kind of a factor.
 But this is here, basically the two Google Chrome screenshots are doing the same.
 They use your local device in this regard, my laptop, to log you in.
 So you don't necessarily have to have a Ubiquity.
 You can also save the key pair that you're using for
 logging in with WebAuthn to your device.
 It might be your cell phone, might be your laptop, and therefore you have the,
 you just need any kind of authenticator that is certified and
 the keys are one way and your laptop and your modern day
 cell phone are the other way.
 And they use the TPM chip on the cell phone or
 like the security chip hardware on the cell phone or
 your computer to generate the keys.
 The Ubiquity has the hardware on like inside built in.
 You can also use as a measure of another factor to log in,
 something like biometrics.
 I don't know if there's iris scan available for
 modern day laptops or computers, but I guess we'll go there at some point.
 You can use Windows Hello and then basically do either password or
 face or thumb or whatever you have.
 In the end, it all boils down to everything you use without the Ubiquity
 is the device and you have to unlock it.
 So it doesn't matter if you have the password or the biometrics.
 You can use touch ID on your phone, but you can always just not use touch ID and
 put in just the password to unlock it.
 And once you log in, your device will query you for
 whatever credential you want to use.
 And this is already one of the backsides of or
 the downsides of using a non extra security token and just your device.
 Because you might also save your credentials like your username and
 password on the same device that you know are saving or using to authenticate.
 So if someone knows your device password, they can just, and
 has your device obviously, so this is like the two things that you need.
 And therefore it's multi-factor authentication.
 You need the device and the password and
 then you can unlock the authentication.
 No matter if it's password or passkey or
 passkey or WebAuth and as second to password and whatnot.
 And this is already one of the downsides because if you lose your phone and
 you have like saved all your credentials into your phone and
 use it as a second factor, it's all in the same device.
 It might not be a problem for people sitting here, but
 just take a look at your coworkers when they unlock their phones.
 Like don't shoulder surf, but just how they do it.
 A lot of people will use gesture swiping on their phones,
 which is very insecure, has been shown to be very insecure.
 A lot of people will use like pin codes like 12345 or up to six,
 whatever your enterprise has set, even in the worst case scenario.
 This is everything you need.
 Once you have set a passkey or WebAuth and credential on there,
 someone just needs the phone.
 And if it's badly secured, you're still screwed.
 And yes, it's the same when you put the UBI key next to the laptop or the phone.
 Obviously, at some point, just imagine you are some IT department.
 Most of you are admins, or some of you are admins.
 You have users, you know every step you do to make them more secure.
 They will find a way to, you know, fuck you over.
 All right, okay, WebAuthn.
 WebAuthn is a specification that defines an API enabling the creation and
 use of strong, attested scope, public key based credentials of,
 you don't have to like, I'll get into some single point of this.
 This is just from the spec.
 So basically, there's a strong public key based credential
 that you are generating.
 It has like, for example, the current UBI key does, I think it should mean ECDSA and
 ED25519, stuff like elliptic curves, modern cryptography.
 If you have an old UBI key, you should not use it.
 But then again, if you use it,
 you're still better off than not using any second factor at all, obviously.
 The FIDA 2 spec has like a minimum security level that you have to use.
 And you can, if you are administering the server that does the authentication,
 you can set the min level.
 So there is kind of a, if your server does not like support EDDSA,
 or I think it should be ECDSA, I don't know.
 But if you don't support it and the user has no other means,
 they can just not register a WebAuthn key.
 The credentials should be attested for.
 This means in WebAuthn speech or in W3C speech,
 that the key requires possession of an authenticator.
 So basically, you need to have a device which is either a security token or
 a phone or a modern laptop.
 And it also verifies it.
 So basically, one is to register, one is to authenticate.
 So the server sees you have the pop key, so
 it assumes you own and have the laptop in hand.
 It has to be somewhat hardware based.
 And then it's scoped, and this is really interesting.
 A key pair is generated per website.
 So this means if you log in and create a, or register a WebAuthn key set for
 Google, your laptop will not, or your device will not reuse it for,
 let's say Amazon, okay?
 This is pretty cool because while your private key will never leave your device,
 and this is the 2019 before we were talking pass keys,
 your private key will never leave the device, you're only handing out pass keys.
 And this is actually cool from a privacy side, but also,
 because when someone finds your pass key, your pop key, sorry, in a leaked server
 database, they have no idea if you used it to go and
 reuse it somewhere else because you can't by the spec.
 But this also means that as a server administrator,
 if you are offering WebAuthn or Fido2 as a server administrator,
 you just get people's pop keys so you don't have to care like top secret for them.
 Like you would have to with passwords and hash them because you need the plain key.
 Because it's only generated for your device.
 People can, attackers cannot use this pop key to log into anything else if
 your customers have their pop keys stolen from you.
 All right, installation, we already done because all modern browsers and
 systems, like it has a footnote,
 most modern browsers and systems already implemented.
 The WebAuthn standard is supported by almost every browser that there is.
 Firefox actually does it, but not to the full Fido2 extent specification, okay?
 There is still some trouble with, I don't use Firefox, so
 I always had a hard time finding combinations that would work and not.
 I think the problem is that you cannot use currently, I think it's,
 what you cannot use is security tokens with pass keys
 in combination with Firefox on mobile or something like that.
 So they are working on it.
 I think it's somewhere in the next two or
 three versions Firefox will also add the full feature set.
 But all the others should do it.
 It comes with a flavor, Chrome based browsers just do it.
 I, what's it called, Safari, WebKit, Mac OS browsers, or Apple browsers.
 They have like a, they used in 2019 when WebAuthn was released.
 People were really happy for
 Apple because they were one of the first to actually support this.
 And now, if you want, now they are going full pass key mode.
 Now you have to enable iCloud password sync if you want to use
 the WebAuthn feature, there's a hand.
 Oh, it's the, I'm sorry.
 Never mind.
 I should not have reacted to hands and stuff.
 My bad.
 All right.
 Where was I?
 Oh yeah, okay.
 It's supported by most browsers or people are doing it.
 Safari, for Safari you need to enable Cloud Sync and that's for pass keys.
 But the main, one of the main features of WebAuthn was that they advertised it.
 That the credentials never use, never go out of your machine.
 So now they like completely turned around and said,
 pass keys basically the credentials do move out of your machine.
 So now you have to think about which one is better, actually.
 All right.
 So talking multi-factor authentication, there's a couple of alternatives.
 Most of you will know the Google Authenticator,
 all the Microsoft Authenticator things, where you have a time based code,
 usually six digits long, that you can generate for a website and
 it will recycle every, I don't know, 30 seconds or so.
 And you have to do the input this after your password.
 Obviously, if you send a string to a server, someone can intercept it or
 can like fish you because in the same way with a password,
 they just have to like use it quicker than your password.
 Your password doesn't expire,
 the TOTP tokens expire after 30 seconds, it's still fishable.
 What's also currently being rolled out by most companies is that you have an app on
 your phone and when you log in on some device, you get a notification on the app.
 You have to click, yes, this was me, I just tried to log into google.com or so.
 So if you get fished, so you go to a fake website and
 accidentally because you think it's the real Google,
 you enter your credentials there, your username and your password.
 How does it help that you have a cell phone when they just like proxy it to Google?
 You just logged in, so obviously you're waiting for
 a notification to happen on your phone, obviously you will click, yes,
 this was me, even though the actual authentication comes from Google and
 not from the phishing side, so yeah, great stuff.
 Looks like this, I managed to input German screenshots, I'm very sorry.
 Like just imagine you are prompted to enter a six digit code into a fake website.
 And the server bot, because it has to be very quickly,
 just uses it instantly to send it to Google or to Microsoft.
 But with a time slice of like 30 seconds left, you can actually copy it by hand.
 So and you can then, after logging in,
 even reuse the TOTP code to add a new authenticator.
 That's not like main of the talk here, we can talk about this later.
 TOTP is not phishing proof.
 So how does WebAuthn work communication wise?
 How where, I'm talking a lot about keys and pub keys and servers and whatnot, but
 how does it actually work?
 So FIDO2 combines two frameworks or two protocols,
 protocol like things, I don't know the real correct word for this.
 So WebAuthn is the communication that happens between your browser and
 the backend server that you're authenticating to.
 It's also called a relying party in WebAuthn.
 And this, as I said, is implemented by most browsers by now.
 And then you have the CTAP, Client to Authenticator protocol.
 This is basically how your browser is allowed to talk through your hardware
 with your security key or with your operating system that acts as the authenticator.
 And this is like in all modern systems can do this already.
 So let's imagine you want to register new keys and
 it doesn't matter if it's passwordless or as a second factor after the password.
 So basically, you as a client with your key authenticator thing,
 you go to the server and you're like, hey, I wanna register a new passkey.
 My name is Chris.
 If you already have a user account, you're already logged in,
 the server knows this.
 Server wants a passkey.
 You generate keys locally, you save the private key locally, obviously,
 because in private public key, you need the private key for signing messages.
 And you give the pub key to the server who saves it with your name on it.
 So next time you tell the server that you are Chris, you can then
 sign a message that the server sends you when you authenticate.
 And the server can then verify, because they have your pub key,
 that you have signed this message with your private key.
 So this is like PGP basics, right?
 Or GPG.
 So I wanna talk about a couple of options.
 So this one, up to now, this is just like the most basic workflow they have.
 Maybe you have seen this picture around the Internet for quite some time.
 And that's what I was talking about.
 Somebody, some administrators in the past added token-based authentication or
 multi-factor authentication to their servers so
 their admins would have to use another device to generate a password or
 a short-term password that they used to log in.
 And then there's people who just hang this up with camera in front on the Internet.
 So they don't have to be in touch with the device,
 which totally defeats the purpose, right?
 And if you're using security tokens or stuff like the device as an authenticator,
 there's multiple options that you can set as a relying party or authenticating server
 to force people or to force your client to use a certain settings.
 Especially for security keys, you usually have a button or
 even a fingerprint reader that is locally saved to the key or
 kind of something you have to press and it's not connected to your computer.
 You have to physically press it.
 So this is like the most basic one.
 You can set verification to discourage.
 So it's just if I want to use the YubiKey to sign in, I must press the button.
 But as a server administrator, you can also decide that
 the security token has to be secured with a pin code that the user has to enter.
 So it's even more factors basically.
 Like I think the most, like if you play it all the way around,
 you can go username, password, you have to have the YubiKey.
 You have to press it so you're physically there.
 Then you have a prompt on your computer that prompts you to enter the pin for
 the YubiKey.
 The server doesn't know that.
 This is a local setting, okay?
 And if you set this to required, which you shouldn't in my opinion,
 there's two possibilities.
 Either the user can enter the key and if they can't,
 like if they don't know it but also obviously if they can't from a technical
 standpoint because their system doesn't allow it for it, they would just,
 you can't log in, okay?
 And then there's something in between is preferred with you as a user.
 It should read user can decide.
 So when I set up my YubiKey, I can with the managing software from the vendor,
 I can decide to have a pin code on my YubiKey or not, okay?
 And the server will respect this if it's set to preferred.
 Okay, then there's a very controversial,
 I won't go through all the settings, okay?
 This is like the second of two configuration items that I find
 particularly interesting.
 And this one is rather controversial.
 There is the option to set a discoverable,
 that's like the name in the spec or non-discoverable credential.
 And then there's again three ways, like the server can decide,
 just don't do it, dear client.
 Then they can say, prefer, then the client can decide.
 But this is like not something you as a user choose, but
 this is like the OS setup chooses and it will use the discoverable one.
 And I talked about what it is in a second.
 Or you can require it as a server site type.
 And yeah, the default is preferred right now.
 I think it's a bad idea.
 I'll come to it in a second.
 So discoverable credential means there is actually a fresh key
 created for this website, as I said before, as was part of the WebAuthn standard.
 Like this is all the same.
 It can include a username.
 So this means I go to Google, they don't support it, but
 let's just imagine I go to a server where I want to authenticate.
 I just put my YubiKey or my NitroKey or my whatever key in my laptop and
 press the button and I have never entered a username.
 It's basically like, it's okay for certain scenarios.
 Like imagine somebody, I work in retail.
 Let's just say a cashier wants to log into the cash box.
 It's okay that they just put the YubiKey or the NitroKey or whatever key inside
 the machine, press the button and they know this is user 1234 and
 they have the password, they don't need the password, it's completely cool.
 And this makes a username-less login possible.
 It has downsides because I have like, I don't know, five Google accounts.
 How would Google know which one I want?
 But since the username is included in the key, I can just send them the,
 I can sign the message, they can just cross-reference it with their pop key setup.
 And at some point they will find an account that matches this,
 that can verify this signed message, so it must be me.
 The problem is that you can't decide on a YubiKey or a NitroKey which key to use.
 Like you can't have, it's impossible to have three keys for different Google
 accounts if you don't add usernames.
 All right, and the other problem is that your security keys especially,
 which are really cool and I would really love to use one on everything,
 they can only hold X keys.
 Like the top NitroKey currently can save up to 25 discoverable keys.
 And this is like the preferred setup.
 I don't know if you have a password manager.
 My password manager has like over 500 passwords.
 If I were to do pass keys on all of those and replace all of those,
 I would need 20 YubiKey's if they all used discoverable credentials.
 Okay, even if they don't use username less login,
 that would cost me like a shit lot of money and
 my key would not look like this, but more like this, okay?
 NitroKey has 50 keys, there's other brands that do more.
 Your laptop can hold basically an infinite number, okay?
 So you don't have the problem with laptop than or phone.
 And then there's the non-discoverable credential.
 And in my opinion, if you don't need the username less login, please use this.
 So if you're an administrator,
 set the discoverable credential setting to discouraged.
 What's gonna happen is the security tokens like the USB keys, but
 also your TPM chip and stuff, they have a master password or master key.
 And this is basic public key cryptography.
 We have a master key.
 And then you get a seed like a nonce or
 string from the server when you are creating and registering a key set.
 And from this master key, you create another key set.
 Because the cool thing is, okay, you can later recreate it.
 You don't have to save this key set.
 So basically, this is how it happens.
 I go to the server, I'm like, hey, I'm Chris, or
 I am actually Chris's operating system.
 So and the server is like, okay, cool, please use this nonce.
 And I have actually, when I was looking over the slides earlier,
 I'm not sure currently if this is 16 or 64 bits, but bear with me.
 It's a string.
 So then I generate from my master key a new key set.
 And then I send the pub key of this new key set to the server.
 And I use the combination of the master key and the nonce for this.
 And the server will send the pub key, but I will save it, but
 will also save the nonce.
 So when I authenticate actually, or use it as a second factor,
 I come back to the server.
 I must say I am Chris, because the server has no way to decide this otherwise.
 So the server has to send me my nonce and a message to sign.
 I forgot this, sorry.
 And then I can generate the keys from the nonce on the fly while authenticating.
 And then I can use the regenerated private key to sign the message and
 send it to the server.
 And from there on, the server can't really decide if I've saved the pub key
 before, the private key before, or if I have recreated it.
 And the server doesn't care, because they say, from a server standpoint,
 if I have the master key and it is branded into the hardware,
 it doesn't matter if you have created a new key or not.
 Okay.
 Yeah, and then the server can verify that it's indeed you.
 All right, so quick wrap up.
 Phishing is, to my knowledge, impossible.
 Because your client will save the actual,
 or will use the actual URL endpoint to create the keys.
 So if you have a key that you registered with google.com and
 someone tries to phish you with fakegoogle.com,
 you won't have a key for fakegoogle.com.
 Even if they manage to pursue it, you want a phishing site to create a key for
 fakegoogle.com, you can never use it to log into actual google.com.
 There's no way.
 The only way would be if there's a problem with HTTPS or TLS,
 because this relies on server certification and stuff, okay?
 But even if you proxy the traffic, there's no way that you can,
 you might have, if you proxy the traffic, now that won't work,
 because you have a different address.
 If you man in the middle the traffic, obviously, this doesn't help,
 because you still get the authentication, or the, what's it called,
 session token, or stuff like that.
 But for, there's no way that someone that can convince me on a fake site to
 insert my credentials, that they cannot use my keys.
 The convenience is pretty high, I think.
 Especially if you use only your computer for not so secure accounts.
 Like imagine, with the alternatives, like you log in on your desktop,
 you put in your username, you put in your password, and
 then you get prompted for a key, you fumble in your bag for your phone,
 you put up, you have to start your authenticator app,
 you watch through your scroll through your, I don't know,
 200 TOTP token settings to get the key.
 You have to type it in, oh shit, the time slice is up,
 you have to get another one.
 Yeah, I think it's much easier, especially if you use stuff like Face ID or
 Touch ID to just tap the touch scanner once.
 Or if you have Face ID to just have the camera scan your face once.
 And this is really bad of me because it should say the server only knows
 the public key, right?
 I'm really, whoops, that would be fun.
 All right, okay.
 All right, let's say the server only knows the public key, okay?
 So there's no way.
 If they have the public key, they have no way of telling who,
 if it's you, an attacker that can extract the public key,
 they can't do shit with it.
 No way.
 Contra, if you use secure tokens, you might have to spend a couple euros on them.
 So I think the cheapest ones are like 10, 15 euros that fit the standard.
 If you like, let's say if you want different devices,
 like use desktop for logging in and phone for the authentication device,
 you can use this through scanning QR codes on the desktop from your phone and stuff.
 You need to, let's say you're an enterprise or a small company,
 you have to give everyone an extra UBI key or an extra phone so
 that they can log in on the desktop if you don't want to have it on the same device or so.
 So there might be extra costs.
 The key might be saved to the same device as the login.
 So if someone takes, as I said, takes the phone, you have weak authentication,
 they have both the login if you save it to the device and also the pass key or
 web-authentic key and yeah, if you use pass keys, I'll skip that.
 Your keys will get synced to the cloud, I'll get to this.
 So now, most big companies are pushing for
 pass keys, Apple does it, Google does it, I think Amazon does it too.
 One password does it.
 You should get rid of their ad is like you should get rid of passwords at all
 because it's hard to remember passwords.
 Use secure unique password, you'll know it.
 People could use password managers, but
 it might be easier to just use like your fingerprint on your phone.
 And I think it's a totally valid thing for probably 99% of Internet users.
 The other thing that they say is it will work on all devices.
 And there my doubts start a little because basically pass keys is just web-authentic
 with a little extras or a multi-device web-authentic as I've read somewhere.
 What is happening actually is if you set a new pass key on your device,
 it will get synced to the cloud.
 So let's say I'm using a Mac, I'm using an iPhone.
 I create a pass key to lock into Google.com on my Mac Safari.
 It gets the private keys gets synced to Apple Cloud, iCloud.
 And then synced onto my watch, onto my iPhone.
 And then I can log in from all these systems.
 That's pretty cool because I can now log in from my phone.
 I don't have to remember the password.
 Let's say I generate a very good password on my computer, on my desktop.
 This is really cool.
 I can copy paste it and then type it on my iPhone for
 an hour if it's like 30 characters long.
 So now the key that doesn't even need a pass key is just synced to my iPhone.
 That's pretty cool.
 The problem is, in my opinion, that iCloud,
 if you turn on password sync one, they know your passwords.
 So if you're using multi-factor authentication pass key,
 like password and key as the second one, then now you give them both.
 It's not worse than before because before you had multi-factor out,
 they knew both too, or that both as the one password.
 But I think, don't get me wrong, this should make life easier,
 logging in securely easier for a very large proportion of Internet users.
 But there's some, maybe even company policy that will stop you from syncing
 password stuff, and this includes pass keys into the cloud, okay?
 So, and now is the problem that you can, if you're a Safari user,
 I said it before, this kills WebAuthn for Safari.
 Because they force you to enable cloud sync, and
 it used, WebAuthn worked perfectly on Safari.
 But now they just killed the feature basically if you don't want to sync.
 Yeah, so relatively high security level.
 It's probably stuff like your mother-in-law or whatever should use
 instead of typing the same three digit or six digit password on every shop they use.
 It prevents phishing, as I said before, it's unfishable.
 You don't have to remember complex passwords actually, because the general idea
 behind pass keys is not as a multi-factor, like second factor next to password,
 but just to replace password.
 The downside is, especially smartphones have no good protection, okay?
 And the problem is with all the syncing tools.
 They, you have no way to choose which passwords to sync.
 So maybe you are cool with having your, I don't know,
 your Tinder password synced to iCloud, but not your bank account password, right?
 There's no way to distinguish.
 Either you sync all or sync none.
 And there's another one.
 You have, people have, like server admins or companies have to give you some kind of
 reset code, because if you lose the device, or for whatever reason,
 all your devices that are synced, I mean, yeah, if you have multiple, okay.
 Yeah, it's really bad.
 You need some kind of backup password.
 Now you have backup passwords for every password that you were trying to replace.
 I don't know if that's, like, in my head, this is kind of like going back to the start.
 It's vendor locked in.
 You cannot, if you use Chrome Password Manager, or one password,
 or whatever other password on your one device, you cannot sync it to your other
 device that uses iCloud, or something like that.
 You have to use all Google account, or all Apple account, or all one password account.
 I said earlier, there's no selective sync.
 Password and sync and key, if you have passwords, are synced to the same cloud device.
 I just forgot one that I got into my head.
 Oh yeah, there's like a point.
 They say you don't have to remember any password.
 But then again, it's all tied to your Apple account, where you need a password.
 Or to your Google account, where you need a password.
 So at some point, yes, it's easier, because you don't have to remember 100 passwords.
 Or your password manager doesn't have to contain 500 passwords, you just need one.
 And I don't know, I've seen people losing their password manager or
 Google password or so, and then you have backup keys.
 What do you do with backup keys?
 Do you print them out and put them in your storage or somewhere?
 Do you write them down in some file next to, post it onto your computer or so?
 No idea.
 So I just want to wrap it up again, one more time, and then you're free to leave.
 Or ask, or discuss.
 The web auth and secure token is, in my opinion,
 like UB key on your key chain is in my opinion the most secure or
 most possibly achievable secure combination.
 And then if you want, you can add shit on top.
 Like from a server admin perspective, yeah, put TOTP on top of it.
 If you're on, I don't know, nuclear stuff.
 I'm not in that business.
 But I would love to see people use a UB key, because that's something you don't,
 I don't know.
 Who of you has lost their keys before?
 Like physical key, okay, sorry.
 Yeah, you need, yeah, if you use UB keys or
 Nitro keys or stuff, it's a little piece of hardware.
 It probably costs them to produce like, I don't know, one euro or so,
 probably less, you buy it in twos, would be my recommendation, okay?
 Or use like an old phone or something like that as backup.
 There's a high convenience level when using biometrics without the security
 token, you don't have to search for your keys.
 That might be like downstairs in your house or
 upstairs in your house when you're working from the cellar.
 You can drive the decision as a server administrator.
 Like what kind of options you set, obviously.
 So if it's a bank account, you probably want higher level security than on
 your Twitter account, it might differ for people, so
 it depends on your attacks or threat scenario.
 Do we have one more?
 Yeah, that's the last one.
 Thanks for joining.
 If you have, thank you.
 >> We will have a Q&A.
 >> Yeah, sure.
 >> If you have questions, please line up at the microphone.
 Please don't cross the camera in front.
 >> Hi.
 Thanks for the great talk.
 It's a very cool topic and I think we will see it a lot in corporate
 environments.
 >> Yeah, totally.
 >> Let's say we don't want to use these cloud features to get the vendor lock in.
 How could we do that?
 So I'm thinking, using the Yubi key has some restrictions with a limited number of
 slots, for example, so why can't we put the private key in our password managers?
 And have the password manager act as the Yubi key, virtually,
 you could then back this up through OneDrive or whatever other IT means.
 >> It's actually, people are working on that.
 This is one of the big things that one password is doing, or
 that they're advertising for, that you can then store or
 use it as a WebAuthenticator next to your, or as an alternative to your device.
 Then again, you have the same problem again.
 There's one company that has all your stuff, and stuff like OnePassword does.
 I think they do cloud-based only currently.
 But yeah, there might be, I'm not aware, but it should be possible
 to have another open password manager that you care for yourself.
 I think Bitwarden is working on it, and this is very likely to be seen in
 at least companies that people around here work for more than OnePassword.
 Yeah, it should be possible.
 >> So my question is quite similar.
 Does WebAuthentic require you to use hardware tokens?
 Is this part of the standard?
 Because if it's not, there's great open source password managers.
 If they adapt to the standard, you can do all your great crypto security stuff, and
 have no vendor lock in, and still use WebAuthentic.
 Because I think WebAuthentic is great, I just want to use the tokens.
 >> Yeah, I'm not sure actually what the aspired spec is in the end.
 I'm very sure that at least most companies that are part of the FIDO Alliance,
 which is the major driver of this,
 let's say would have a hard time of you using open source.
 You know, it's not in their interest to do this.
 But if there's, like OnePassword for example is part, and they have this exact problem.
 It might be possible that you would need the hardware
 security chip on your device to create the keys, but
 then save them to your password manager.
 I don't, yeah, I don't know why it should not work.
 But I'm like, I don't know actually.
 Sorry.
 >> Yeah, thank you for the talk.
 To the best of your knowledge, how secure are the UB keys themselves?
 Like several months ago we had the entire story with Ledger where it was like,
 we can actually totally export your key material from it.
 >> I think there was in UB key four up to a certain serial number or
 certain level version, they had a problem where theoretically people
 were able to recreate the master key due to some faulty implementation.
 But I'm like, I have no idea about crypto at all.
 You know, like when I was preparing the talk,
 I learned that you call that string to verify from the server a nonce.
 So my crypto level is very, very basic.
 I think generally, I would imagine if a company like
 Google, which is known to have very little breaches, I think,
 that I know of, uses security tokens, they will have this thing covered.
 I'm very sure that they have thoroughly tested all these things.
 But yeah, it's just, if there's no flaw that people know about,
 doesn't mean it doesn't exist.
 >> Do you know which brand does Google use?
 The question was, because he has no mic, which brand Google uses.
 A couple years ago, I think it was 2017ish, Google came out with
 a set of blog posts that they were using Titan keys.
 And they have, it's just another brand,
 the chips come probably out of the same factory in China somewhere.
 But they're using Titan keys, I don't know how it is yet or now.
 And they also had an advertising thing where they enabled you to buy a set of
 Titan keys that do Bluetooth and NFC and USB and whatnot.
 Okay, so, but generally, I don't want to advertise for one brand, I don't know.
 What I can recommend when looking at keys, like security token keys,
 think about what kind of adapter you are using most with this key.
 So if you use, like I have a MacBook Air some kind of years old,
 it has only USB-C ports.
 My phone has USB-C port only.
 If I use a USB-A port authenticator, then I can show you,
 it looks like this all the time, so you need an additional adapter all the time.
 And then I would imagine you run around with your key chain and
 the adapter falls off and stuff.
 So think about it first, they have it in several different specs.
 You can also use NFC, just hang it to the back of your phone.
 That's pretty cool, but yeah, in the end, I can't recommend a brand actually.
 >> Thank you, Soy.
 >> [APPLAUSE]
 >> Yeah, if you have-
 >> [APPLAUSE]
 [Music]