 Hello, everybody. My name is Alex, and I'm addicted to passwords. Welcome yourself. Thank you. It's been four minutes since my last login. My addiction started in 1996 when I typed sesame into my new free server account. One password became 10, 10 became 100. I've since lost count. Some days I go through thousands of bits of entropy in a single session. With your help, I hope that I can get through this problem. So I won't dwell on this. We all know that passwords suck. Everybody, myself included, and I'm certain a lot of you chooses one, two, three, four, five, six. The same password I use for my luggage. We reuse them, we write them down, we share them, and we get inevitably fish, and we still forget the bloody things. Equally, from the point of view of the server, passwords are a pain in the arse. The complexity rules just keep getting more kafkesk as we progress. There is such a thing as a lowercase number. I'm not sure it's possible to get three unique symbols out of two, but somewhere some password requirements want you to do so. And a coesium is two weeks, if anybody was wondering. And don't worry, your password is stored securely. It's getting worse. They're breeding like cockroaches. I'm sure there is somebody in this room that has a password database upward of 500 or 1,000 passwords. Strong passwords are just too complex for the human brain to remember. Usable passwords are just too weak to be of any use. And Moore's law is progressing. The bar is rising. To top it all off, we've now got games consoles, phones, thermostats, all manner of crazy internet-of-thing devices asking for your password. And yes, you still do need to have three symbols, a mixed case and a digit. I'm part of a fine tradition today predicting the death of the password. Bill Gates predicted it in 2004, IBM in 2011. Wired magazine predicted the death of the password in 2012. So did Google in 2013, the Wall Street Journal in 2014. I'm sure that there is somebody in 1970s predicting the death of the password. Taking a bit of a liberty, but I think even Winston Churchill understood where we're coming from. The problem is not that passwords are bad. The problem is that passwords are the least worst option. They are the least common denominator. They work or kind of work everywhere. When we compare them to the alternatives, federated logins, people know what they are, but they're fragmented. Was it your Google account? Was it your Facebook account? Was it your Twitter account? Was it your GitHub account? Was it your Mozilla OpenID account? It's hard to remember. Passwords are free to implement and deploy. They come out the box with Django and various other web frameworks. Federated login requires a slightly more effort, but it leaks tracking data. Every time you log in with your Facebook account to Wired magazine, Wired knows, but also Facebook knows. So do the advertisers that partner with Facebook. You can't use your Facebook login to log into your thermostat. I checked. The distinct advantage that federated logins have over passwords is that the reissuing to credentials is somebody else's problem. If we compare passwords to hardware tokens, hardware tokens are still weird. It's just banks and big businesses and enterprises that use them. So I wouldn't be happy giving a secure ID token to my uncle Horace, let's say. In addition to that, they're proprietary. If you want to use an RSA secure ID, you have to use it with RSA secure ID software, and you can't substitute another token if the secure ID becomes expensive or unavailable. They're hard to deploy. You have to physically post them out and they're hard to reissue because you've got to post out another one. Software tokens have become a bit more popular in recent years. If you think of Google Authenticator, they're often also paired with the SMS technique of sending a six-digit pin via a phone call or as a text message. They require a bit of training. Again, they're fragmented. There is a standard in theory. You don't have to use the Google Authenticator application. You can use any application that works with that OAuth standard, but it's a bit hit and miss. You usually don't need a third party to use such an application, but some of them do and they do leak metadata when you log in. Biometrics, they're familiar. Everybody's seen iris scanners and fingerprint readers in the movies. So you don't need to train people how to use them. Biometrics is that's about the only good thing about them. They're proprietary, they're expensive, they're hard to deploy because nobody has a fingerprint reader unless it's on an iPhone. They're impossible to reissue until cloning comes along. And with the exception of the iOS platform with Touch ID, they're almost nowhere. If you're stuck with passwords, what can we do to mitigate this travesty? The first one is that you might want to switch out your password generator. I'm sure you're all familiar with a certain XKCD cartoon. I won't mention it by name, but if you'd like to use it and you can't be bothered to code your own, I highly recommend horsephrase. Pip installable comes with a command line tool and you don't have to give it any special incantations to give a nice familiar XKCD style password. Studies have shown that this style of passphrase is easier to use than the mixed case symbols, digits type. And if you need extra entropy, just add another word. Similarly, horsephrase, just as it's usable from the command line, does of course also a module that you can import. If you have to use the mixed case digits, at least one uppercase, then you can make that a bit easier to type on phones and games consoles and thermostats. And I'd like to try a quick experiment with you all. Could you all get out your phones or your tablets and try to type that password? You don't have to type it into a password field, just any text editor or note application will do. I'll give you all a minute or two. Raise your hand when you're done. Fantastic. How many times did you have to switch keyboard? Did anybody make mistakes? Yep. So, on average, depending whether it's Android, iOS, different versions, it takes 24 taps or nine keyboard changes to type that password. And it's a typical randomly generated, considered strong password. Now I'd like you to try this variant. Raise your hand when you're finished. Sorry? Yes. Okay, so we've got a few raised hands. Was that easier? So, the improvement is you save about seven taps and you only have to change keyboards twice with this variant. This comes from some research done by the US National Institution for Science and Technology, and they find that on average you save a certain number of taps and a certain number of keyboard changes by permuting passwords like this. If you'd like to permute your own passwords, I've created a Python package for it. You can use it from the command line or in your Python software. The link at the bottom will take you to a summary of the research. By permuting the password you do lose some entropy, but you can typically regain that lost entropy by just adding one or two characters. And the research summarises the bits of entropy lost and gained by the permutation and adding extra characters. I hope to be able to get this integrated into key pass or to provide it as a plug-in in the coming month. Now, if you're running a server and you're fed up with your users choosing 1, 2, 3, 4, 5 yet again, the classical way of combating this is to ask for mixed case, symbols, digits. No repeating, not the same as your username. They're all ad hoc rules. What you really care about is entropy, but it takes a bit of maths to measure entropy, so very few people code it up. Luckily, you don't need to. It's been done for you. If you're writing a Django app and you'd like to get rid of those annoying rules, but you'd still like to encourage your users to have strong passwords, then you can use Django ZXCVBN password. It's a Django app that is a mixture of Python and JavaScript. It's based on an underlying package called ZXCVBN, and it measures the entropy of the password based on the username and the current day and a few other signals. As the user types a new password, it gives them an interactive strength meter, and again, there is research that has been done to show that if you provide this interactive feedback, it encourages users to pick a strong password without antagonising them, without driving them away as much. Because, of course, when somebody is creating an account, you don't want to drive them away with repeated validation errors on their new account. If you'd like to use ZXCVBN in other frameworks, then the Python package index page for this Django app also links to the underlying package that you can use yourself. Another thing you can do to make your users' lives easier is to let them see the password. We've taken it for granted that you should hide the password when people are typing it for years. Now, that made sense when the password field would always appear on an office computer in the middle of a load of cubicles with people passing behind without you being able to hide the screen or on a shared terminal on a main frame, but those days are passed. More times than not, you'll be typing a password on your phone or a tablet or your laptop, and there won't be anybody else around. So why hide the damn thing? The safest thing to do so as to not scare your users away and make them think that the form is broken and insecure is to, by default, still hide the password, but provide a little tick box or clickable icon so that they can show it. The link below goes to the page from which this screenshot is taken and shows more examples. I'm afraid I don't have a pre-packaged Python solution for this. So it is a standard feature of login dialogues on Windows Internet Explorer past a certain version. That has a slightly unusual implementation in that rather than that I symbol being a toggle, you actually hold your finger down on it on a touchscreen or the mouse button, and it shows as long as it's being clicked on, like a dead man switch. So this is ongoing usability evolution. There's a very good chance that browsers will implement it like this by default, but it's not happened yet. Ideally, if this ever becomes a reusable HTML component or some form of HTML5 thing fall back, it should take into account that it could become a native feature. The final mitigation that I'd like to suggest is that please, please, please don't disable auto-completion, don't disable password managers. The second example you see there was called out, British Gas were called out quite recently for doing this on Twitter, and thanks to a, what's the word, Twitter, not hate mob, a Twitter mob brandishing pitchforks and torches, British Gas will be reconsidering their practice of using this. Unfortunately, umpteen banks and city councils, county councils still think that they shouldn't allow you to save password. Unfortunately, the only way to get them is one side at a time. So that's more or less all I have to say about passwords. The next thing I'd like to introduce to you is a new standard or a new pair of standards for authentication. They come from a body called the FIDO Alliance, which was set up about a year ago to fix strong authentication. As I said earlier, the problem with all the alternatives to passwords is that they tend to be fragmented, proprietary, unfamiliar, and generally un-standardised. The FIDO Alliance's mission is to fix all those things. They've released open specifications. If you pay them money, they will do certification testing for you and give you a logo and a trademark that you can use and stamp on your products, but you don't have to do that. And it's based on public key cryptography. Think of the Wi-Fi Alliance a decade or 15 years ago when wireless internet was still a weird thing. They are the Wi-Fi Alliance, but for authentication. The aim of the standards is to allow multiple authentication methods, such as dongles, fingerprint readers, pins, smart cards, mobile phones, whatever, to all be usable against the same API and all be usable no matter what the transport is, be that USB, Bluetooth, NFC, something we haven't thought of yet. It's a single browser API no matter what combination of those gets used. And because it's based on public key cryptography, no sensitive data leaves the user's authenticator. So there's nothing sensitive on your server to be leaked out and there's nothing sensitive in the browser to get phished. So if, God forbid, your user database gets leaked, the only sensitive information that will get into the wild is things that you've specifically chosen to gather. The Wi-Fi Alliance standards don't require that you gather an email address. You can still gather an email address and if, God forbid, your server gets breached, an email address is the worst thing that will get leaked. There are no password hashes within the FIDO Alliance standards. Like I said, it's an industry consortium. The big backers are Google, Microsoft, RSA, ARM, Samsung, PayPal and a host of others. They're the internet companies that are as fed up with authentication as you are. And it's ever-growering. Recently they accepted their first government members. So the US Government National Institute of Science and Technology has joined and so has the UK Home Office. There are two standards that have been announced by the FIDO Alliance. The first is universal authentication framework. This is the one that is designed to replace passwords. The second is the universal second factor framework. That's the one that's designed to standardise two-step authentication. So you still have a password under U2F, but it doesn't have to be as strong because you've got a second factor. It could just be a pin if you wanted to. No matter which of those two you choose, the way it works is the very first time you open an app or visit a website, you'll be asked to register. And it can but doesn't have to ask for a username and email address. But when it comes time to set up a secret, you would activate your authenticator, be that your mobile phone or a USB key or something else. Your authenticator would generate a new private key. That private key is only used for this pairing. It's not used for any other. So if two different websites are used against the same key, there is no way that those two websites can know it's the same key. It's just a different private key they see. Private key is stored in a secure element on the authenticator. And the authenticator sends back to your website or to the app a public key and a key handle for use in future authentication sessions. Once the registration is complete, the server stores the private key against that user's identifier, username, email address, whatever, and can be sent back to the authenticator as a challenge next time. Authentication looks almost identical to registration. The only difference is that when the user is asked to activate their authenticator, it uses the key that it previously generated to sign the challenge that was sent. So to give you a concrete example with some code, this is a pseudo code python web server that's handling the registration for a new U2F device. The library we're using is an open source BSD licensed package provided by Ubico. It works with Ubico keys. It should also work with U2F authenticators from any other provider. The app ID you see there is just the domain of our website. It must be HTTPS. You cannot do any Fido Alliance authentication over an unsecured channel. We simply generate a challenge, store it in some session or against the user's username, and send that challenge to the client. The challenge that gets sent is just a short snippet of JSON. It's all base64 encoded, so it's safe to stick anywhere that you... You don't have to worry too much about binary encoding of it. The challenge that you see there at the bottom is just a randomly generated string. There's no structure to it, and you can generate as many as you want and throw them away. You don't have to worry about losing them. So that challenge gets sent to the browser. The simplest way of doing that would be to just put it in a hidden field on your registration form. Within the browser, the U2F provider provides a JavaScript API, which we call U2F.register with the challenge that we generated server-side. That takes a callback that accepts the response generated by the authenticator. So what would happen when this JavaScript gets run if this little authenticator was plugged into the laptop? A little green light starts flashing there. As part of your page, you put up some text saying, please activate your device now. I, as the user, touch that, which allows the authenticator to respond. It's had a proof of human presence. It generates the new private key, returns it to this JavaScript. The JavaScript sticks it in a text field and submits the form. The response, again, is just some JSON. The challenge is exactly what was sent by the server. The client data and the registration data are generated by the key, and they are cryptographically attached to the challenge. So if somebody changes the challenge on the wire, the client data and the registration data will not validate. The app ID also is what was sent by the server, has to match if that gets changed, if somebody tries to do a man-in-the-middle attack, all the signatures will fail. It is. But it doesn't matter that it's a UB key. It just has to be a U2F authenticator. Final step of registration on the server. We received the challenge that was sent by the, sorry, we received the response that was sent by the U2F authenticator. We retrieved the challenge that we generated earlier. We call U2F.completeRegister with both of those. That takes care of all the cryptography for us, checks the signatures, and returns a registration object. That's just a Python dictionary that contains a key handle, the public key of the authenticator that was freshly generated, and the app ID that we generated all the way back. We save those three things for future authentication. That's just an example of the registration that is returned when we call the completeRegister function. The thing that I'm going to skip over there is the attestation certificate. That is so that you can say, I will only accept signatures from brand X. If you want to restrict yourself to just UB keys, or just Samsung phones, or just some particular brand, you can do, they all contain a manufacturer certificate. The manufacturer signs that certificate, and there is an online database that you can check that attestation certificate against. For simplicity, we're just going to skip over that right now. Authentication is almost identical. On the server, we generate a challenge. The difference is that instead of startRegister, this time we use startauthenticate. Again, we save the challenge that we generate. The challenge looks like this. App ID is the same as it was during the registration. Challenge is a freshly generated random key. The key handle is what was returned by the authenticator during registration, and it's how we identify this key. Again, on the client, receives the challenge, submits it to the authenticator. The authenticator starts flashing or doing something bingley bingley beep so that it can get your attention. The user activates the authenticator, and the authenticator then returns a response that you can transmit back to the server. On this, you just press the gold circle. That doesn't prove it's me. It proves I'm present. This is a U2F device. The idea of it is that it is a second factor. Obviously, this is cryptographically unique. It's got a private key inside that was burned in at the factory. It's tamper evident, that sort of thing. It's only useful as a second factor, not as a universal UAF device which would have something biometric in it so that not only was it proof that it was the person present, but by the fingerprint or their retina, it would prove that it was them. Yes, but the point is you couldn't use this as the sole authentication factor because effectively it's a bearer token. If someone steals it and it was the sole factor, they would have everything they needed to pretend to be me. So, final step of authentication. Like I say, this is a U2F device. This is the second factor of two for a login with this. First, as usual, we verify the user's username and password. Assuming that's correct, we get the associated device that was stored during registration. We then call verify authenticate, which gives us a counter and a flag as to whether touch was asserted. In the current version of the standard, touch is always asserted, so that will always be true. The point of the counter is that, although this device is tamper evident, it could have a vulnerability of some sort. The counter is an indication of whether this device has been cloned. So, if somebody could get in there with a microscope or, I don't know, a very powerful magnet or an x-ray machine or something, they might be able to clone this. If they did, and we were both using it, there is an internal counter that would be... It should always increase, but if there are two of them, sometimes you would see a counter be returned that's less than the counter that you saw last time it was used. If that happens, it means someone's cloned the device and you need to take some sort of action. It could be send the user an email, lock the account. It depends on the particular application. Assuming all's correct, you then just store the new counter value, save the device, and the user is successfully authenticated. This being a second factor, you don't have to use it just at login. You can choose to do it when the user starts a sensitive action, like entering the admin section or transferring $100,000 to Nairobi. You can ask for additional authentication at any point. That brings us to the demo, but before I do that, does anybody have questions about the code? Thank you. Not entirely about the code, but if you have an authenticator on your mobile and your register, how do you authenticate on your laptop, by instance? Jumping ahead a bit, the vast majority of deployed hardware at the moment just works with USB, but the standards include transports for Bluetooth Low Energy and NFC. I would have to connect my laptop to my mobile phone using Bluetooth. It would be Bluetooth Low Energy, so you wouldn't have to pair the two devices, though you could. Basically, the browser, if it supported that form of UAF or U2F, would have a Bluetooth stack in it. It would ping for local devices. Your phone would be listening. It would send a message that says, Yes, I'm here. Yes, I am a UAF authenticator. The browser would then send back, I have these key handles. Do you know about any of them? Yes. The phone would go bingly bingly beep and ask you to authenticate. Thank you. Any others? Time for a demo. It's on that side. Some sort of sticky edge on the screen. I mean in software, not physical sticky. This is the demo application of a Django application called Django Two Factor Auth. It currently supports the Google Authenticator app, SMS, phone call, or plain old UB keys. I've extended it to also accept U2F devices, so I'm currently not logged in and there is a secret page that I cannot view. So I'll just log in. Saved password. I thoroughly recommend password managers. I haven't yet enabled Two Factor Authentication on this account, so I cannot view the extra secret page, which requires additional verification. So I need to set up Two Factor Authentication. Here I can choose between the different versions. In your own Django application you probably choose, you probably provide, you probably offer fewer choices just to keep things simple. I'm going to go with U2F. Insert the dongle. I'm sorry you can't see it, but I do promise that there is a little green blinking LED here. I touch the dongle to prove that I'm present. Sorry? So that JavaScript that I showed you earlier, the callback, when it is called, just inserts it into the input with that ID. In a real world application you wouldn't have that box there. What you'd show the user is just an animated thing saying, now please activate your device. And the second that they did, you submit the form and return it. I'll come onto that at the end. So I'll complete registration. I'm done. There's one number at this point. This is a standard feature of Django 2 Factor. This is just an example app so it's not actually wired into Twilio but in a real application it would be. So I'll just register that phone. Cheat, yeah. So there we go. This accounts now registered to Factor. And I can view that secret page now that requires two-step authentication. If I log out, log in again. I have to choose password and I can choose whether to use phone authentication or not. I'm going to touch the device and I'm in. That is two-factor authentication without having to dig a phone out of your pocket and type in those six bloody digits. So to answer the question about what support it requires, if you want to see any of the code for that demo, those of the URLs, I will be uploading these slides, tweeting the URL and also putting the URL on the description page for this talk on your Python website. I'm afraid the code that you've just seen running isn't available on PyPy yet. I still need to convince the maintainers of the upstream projects that my pull requests are worthy. So to browse the support, I'm afraid this is the bad news. The only thing that supports U2F at the moment is Chrome. It's Chrome on any platform which is good and Chromium. Firefox have a bug open to add support. It just needs somebody to do the work. They're not opposed to it or anything. In a few days time, Windows 10 will be released and the new edge browser will support U2F and that won't just be USB tokens. That will be biometric devices like fingerprint readers or iris scanners built into laptops that support Windows 10. For the hardware support, the only thing that the browser singular supports at the moment is USB. Standard for Bluetooth and NFC was released on the 1st of July this month. So expect support for more devices in the coming months. In terms of phones that support it if any of you have a Galaxy S5 or a Galaxy Note 4 congratulations you have a UAF authenticator and you might already be using UAF to log into PayPal. The PayPal application support uses UAF on those devices. Android M phones Google are making a push for fingerprint authentication in Android M. About time, touch ideas have been stomping on Android's lunch for far too long and you will see more phones with fingerprint readers in the next few months being released. Qualcomm are one of the FIDO members and their new hardware supports it out the box. Possibly even it will be ultrasonic fingerprint reading so you can touch anywhere on the glass. If you'd like more information the specifications are available. There is a tutorial that goes into the steps that I have in a bit more detail. There is a nice video that gives you a history of FIDO Alliance and the sales pitch and if you'd like to use any of Ubiko's open source libraries they were until recently GPL but they are LGPL but they are now re-licensing them as BSD you can use U2F with Ubiko tokens or in theory any other token for SSH login for PAM there are Python bindings there are Go bindings there are JavaScript bindings you don't have to be in a browser to use it the client application just has to implement the wire protocol that is standardised. That's it, thank you very much. I think we do have time for questions and we have questions. Thank you. My current impression is somehow that the only proof that you are willing to authenticate is your super secret password you enter manually is this correct? So there are two standards from the FIDO Alliance. I speak of U2F so U2F it is two factor authentication you are proving that you know a secret password and you are proving you own a particular device and have control. That's understood, but a proof that you are willing to authenticate is the password, right? Sorry, could you repeat that part? Your willingness to authenticate is that you type in your secret password that you have remembered or in a password manager. I would say that's part of the proof that you're willing to authenticate. The proof that you're willing to authenticate is that you both that you complete authentication. The act of doing it is the indication that you're willing to do it. There's a second proof that you're willing to authenticate and that's pressing the button. The button on the U2F device when you show it again the Yubiki and Neo, I guess that little button in the middle that is blinking and as long as this button is blinking nothing happens and this device will only respond to the challenge if you click this button. That doesn't need to be me, exactly. But that's why you should use this Yubiki as a second factor. You shouldn't... I won't recommend you to shorten your password. I would recommend you to... Yes, exactly. You should use a strong password and then use this as a second factor only to to increase security because your password could somehow get cracked, probably. So... So, yes. So U2F is not a replacement for a password. Depending on the application you could choose to allow weak passwords but you don't have to. The true promise at least from my point of view of the Fido Alliance is when the UAF standard comes about and that mandates that the authenticator not only proves that I'm present with just pressing a button but also proves that I'm me by some form of biometric or typing in a pin or something else. So I agree that biometrics are not the greatest thing. They are mitigated in this case because the biometric data doesn't travel over the wire. It never leaves the authentication device just like Touch ID on iPhone. I'm happy. OK. No one's ever happy authenticating. I think we'll take out the questions anyway. If I understood that standard correctly it's required that you have a physical device, right? So you can't have let's say a third-party application on your PC. So the specification strongly encourages you to make it a physical device specifically something that is tamper-evident and has a skewer element. But you have to anyway because you can only connect using USB, right? Well, if you are at the kernel level you can pretend to be a USB device. OK. There are there is a there is a Chrome extension that is a soft U2F authenticator. It has a particular key when that when you as the server receive the registration data that would be evident in the attestation certificate. So there's nothing in the wire protocol that says it must be a hardware device. Wire protocols can't enforce that. But you, the server has access to a metadata service that includes the the manufacturer's signatures of various different devices. So Ubico has signed their certificate. Samson has signed their certificate. Other providers have signed theirs. Any software implementation of an authenticator would have to have a manufacturer ID. It would have to be available in the metadata service and you could choose to blacklist that or whitelist only Ubico devices when registration occurs. Thank you. Hi. I have a habit of losing things and if I if I'm using one token to access everything on the web and I managed to lose that it sounds quite anyway. How would you deal with that? So two parts to that. Any any website or application worth its salt that implements your application will either force you or strongly encourage you to set up some sort of backup method. That'll typically be his eight six digit codes writing down on a bit of paper and keep it somewhere safe. Or it'll be please give us your mobile number, we'll text your messages backup or both of those. The Django two-factor authentication app lets you do the other part of it is that if I lose that it's I've lost it. It's small, it's black, it's not going to turn up. If I lose that it's got onboard GPS it's got an onboard radio I can ping it remotely I can ask it to ring itself if you're going to keep all your eggs in one basket that's a pretty good basket. Yeah I had two questions one of them was already answered. Still I'm a bit confused because you start by saying well passwords have issues and what not but then in the demo the first thing you do is you type in a password and then you use the password manager to store it so basically put your memory inside your computer and then you use the second authentication using your token which well I'm not convinced never the like others that it's a suitable solution. Now I have a question how is this any different from Google Authenticator in the sense that the Google Auth actually is convenient it's a six digit number that is changing all the time and is synchronized with the clock somewhere and there's actually Python memory that does exactly the same job it's called wind time password I think and there's whole math behind that to justify how good this is or a physical device will actually is better than something which is purely software. So Google Authenticator in the one time password standard that it's based on do require that the server stores the seed that generates those six digit numbers every 30 seconds so if there is a server breach there is secret data in addition to the password to be lost. With these the server is not storing anything secret. I find this more convenient than typing in a six, going to the Google Authenticator app and typing in the six digit number but it you have the choice of what you want to use. You can use this with your Google account by the way either as a UB key or as a U2F device and if you want a dedicated U2F device from Uico it's cheap about 15 euros. Sorry I forgot the other part of your question. We still have time for one very short question. And this is a yes or no question. In the FIDO standards is there any capability for duress passwords? This is the case where someone is putting a gun to my head and I need to log in to my bank but I want to indicate to my bank I want to be able to successfully log in but also indicate that I have a gun to my head. So it's a second password that also works but indicates a bad condition. So in the case of U2F your duress password you would type that in as the first factor I guess. That wouldn't be part of the U2 that wouldn't be part of the FIDO exchange. In terms of UAF I haven't seen any reference to that. This is speculation now. The only way I can think of doing it would be if you tap the device it does a normal authentication if you press and hold it does duress. But I don't know if this could be a programme to do that. I don't know if there's anything in the FIDO standards for it. Right. Thank you again.