 Hello, PyConnisters, it's my pleasure to introduce Yuri Ackerman who's going to be introducing us and talking us about universal second factor authentication. Thank you very much. So hi everyone, as we said already, I'm going to talk about universal second factor authentication or why current second factor authentication or blah, blah, blah, blah. My name is Yuri Ackerman, I'm a student at Victoria University and I'm a developer from Sani Wellington. This is a gift I hope will work, there we go, yeah. Today I'll be partially speaking on behalf of Ubico. Ubico is a hardware manufacturer specialized in hardware authentication solutions such as multi-fact authentication devices, commonly referred as UBICs. And we as well produce hardware security modules. Ubico has been setting world standards for secure and easy authentication for some years already and it's been major contributed to finding universal second factor authentication standard. And it's going to be used in more than 150 countries. Disclaimer, I'm not a security expert, so just don't take my word for granted, do your own research, ask people who are experts in these areas. So there we'll look at why my mouse on the screen. We'll look at why password has not solved all problems with authentication. We'll look at why second factor authentication has not solved all problems with authentication. We'll do an introduction to U2F and how it works. We'll do the demo and we'll wrap it up with Q&A. So why not just passwords? And let's look at typical password life cycle. So firstly, people use weak passwords that led to the fact that attackers can really easily gain access to their accounts. People then reuse those passwords if you break one account, you get access to the other accounts as well, and then people get phished. So it's all becomes a total nightmare and how do you solve it? The solution is second factor authentication, AKA2FA. So what is second factor authentication? So passwords verify that you know some secret. If I take my secret and give it to someone else, someone else will be able to verify that he knows some secret. If, and it's obviously doesn't work because you can get phished and we need to do something about it. So we're going to do second factor. It's some other way that you're not just the person who should know the secret, you're not just the Bob that knows the secret. You're the exact Bob that should know the secret. Common life example is your credit card. So you have pin, your first factor, and you have credit card, your second factor. If you give away your pin, then it's obviously going to be useless without the credit card, the second factor. Do people use second factor? I hope after the talk everyone will start to use at least 90% of you. So what are second factor solutions look like today? There's three main types. There is applications in form of TATP and HATP, which stands for time-based one-time password and HMAC-based one-time password. What's pretty much is using the master key and a counter, you derive a 30-bit derivative MAC, and that becomes your one-time password. And a great example of that is Google Authenticator, that you probably many of you use. Tokens are hardware solutions. They can be USB and non-USB, USB divided into PKI solutions that utilizing public key cryptography to perform second factor distinction, and there is obviously OTP tokens that you just press the button and generate your one-time password the same way as TATP and HATP application do. And there is non-USB tokens, and they're just, as you can see, there's a bank token in the bottom. And lastly, there is OTP through SMS. You just receive code, you type in, you press OK, et cetera. You would have Facebook to utilize as that feature. So we have solved it. And there's currently existing UTF solutions, and you can probably just go away and this talk will be finished. Right? Right? Not really. Let's look at why second factorification has pretty much badly failed. So we're going to start with apps. Firstly, OTP is fishable, so that means that if your user gives away his username and password, what's exactly going to stop him from taking his phone out, reading his code, type it in, press OK, and giving this code to the attacker? Nothing. User experience is really poor. People get constantly frustrated with the codes. They regenerate, people mistype them. People have to be twitched as well. So if you attack support, you would constantly get a call or something like, I can't communicate because your service is broken, but in reality people tend to make mistakes. So user experience, people get frustrated, user experience is not the greatest. Applications require shared key between your application and the party, and they are required to share and they are required to sync time. And so it's not exactly always the problem, but if your company distributed around the globe, this will be a major issue. Tokens, as I said, is a hardware solution, so they are very, very expensive. In the previous slide, you could have seen RSS UQAD 800, the B-Stick. This thing costs 54 US dollars. So if your bank and your client holds $10 million account, then yes, this is a solution you can provide your customer with. But if your forum about page KDE for BSD and anime, you will probably never be able to afford to provide your customer or demand from them. Tokens require drivers, and we all can agree that no one loves drivers. They're fishable because they're mainly OTP solutions and some PKS solutions are fishable as well. They, Tokens, have pretty poor user experience because they're OTP pretty much, they're centralized solution. So that means that Tokens are strongly binded to the domain of the issuer. So for instance, if you're banking you should token, you can't just take this token and use it in some other bank. It's have to be this specific bank. So it's not universal solution. Lastly, they're fragile. They have battery. They've really badly done. They break and they're really expensive to replace. So SMS at this stage is the most popular solution on the planet. So it's gonna have the most issues to talk about. So firstly, they're still fishable because they still want a password. They still have this user experience issues because they still want a password. There's a major privacy concern because you have to give away your phone number. And if the database with your phone number get leaked, this is a massive hole which you can utilize for spam, for fishing, for harassment, and we all don't want to have that. There's a major security issue with SMS. And I'm not actually gonna talk about the fact that you can, for about 600 bucks, you can build your own JSM station and spoof someone's SMS codes. I'm gonna specifically talk about social engineering issues that we have to mitigate. So firstly is SIM reissue. Your provider has, your mobile phone provider, they have such service. So if you lose your phone, you can recover your SIM card so you don't get, so you don't lose access to your account. And the only thing you need is provide three, four phone numbers that you called in the last day. So as you can see, there's already a major window for social engineering attacks, especially if you know a person really well. Other issue, and that's not the only case. If you have a buddy inside your mobile phone provider, he can reissue the SIM card just simply by utilizing the functions of reissue which they quite often they do. That doesn't require any verification or whatever. And this can be issued not just in Auckland or then either, this can be issued in Wellington if you never hear that's been issued until you suddenly your phone stopped working and your account's been hacked. And this being, and it's not like, it's not a one of case or it's totally come up, that I came up with. This thing constantly happened in US, UK, Germany, South Africa and a major issue in Russia where a specific load of banking is stuck to the usage of SMS for a lot of verification. Another thing is that SIM spoofing. If you're a government agency, you probably have really good relationship with telecommunication providers. So you probably can come to them and say, hey, can you please redirect these OTP codes to my phone number? Because I really need to get the access to this guy's telegram account. And we know that because this recently happened to one of the Russian opposition members who had his telegram account hacked this specific way. Another issue is coverage. So obviously SIM, SMS required coverage. So if you leave the country, you generally lose the access to your SIM card because you don't tend to turn it on in Germany since it will cost you a lot of money. And so this can be really painful. You lost access to your second factor authentication, so you can't perform secure login. And Australian government actually had this issue and they solved it really easily, simply asked their people to disable second factor authentication, which sounds like a totally awesome idea. And lastly, it's all led to the fact that National Institute of Standards in the newest release of security guidelines on SMS simply banned usage of SMS as transport for one-time passwords. And you know, I talked about use experience. Here's a couple of examples how much people actually do hate OTP tokens. So this is a screenshot of somebody found on the showdown, a live accessible webcam with the RSA security token streaming online. Here's a couple of instructions how to make such things, which I have not delivered to search. This is actually a search for bank token and RSA tokens. This is what came out as some of the pictures. This is why I thought about it. And this is what generally people think about RSA security in first place. So current state of second factor authentication can be described by a word from Pleasant Sanchez, which sounds like a well-marketed catch word. But in deep meaning, it means, I'm in a deep pain, please help. So how do we solve it? We need easy to use, open, secure, and standardize protocol. It's going to use it to university second factor, aka U2F. It's made by FIDO. FIDO is an alliance of more than 150 companies whose goal is to create, secure, easy to use, and open protocols for the web. Three board members consist of the companies like Google, Amazon, Ubicore, PayPal, MasterCard, Visa, Microsoft, which actually been a major contributor to FIDO Alliance. So how does U2F works? So from user perspective, it looks like this. User antics, his username and password. The service provider, their relying party, figures out that user has U2F device registered with the user account. User antics, the key impresses the button and he's authenticated. So on the browser level, it's a bit more complicated. Here we can see a secure U2F element that performs all the cryptographic operations in the chip. And this is optional, but it's a good thing to have. And top we can see user action. It's just a way to confirm the user's present and later I'll explain what's important. And on the bottom we can see a stack of transfer protocols that U2F currently supports. So this U2F authenticator, U2F device, talks to the FIDO client, which in current case is a browser. Browser has U2F JavaScript API, which is utilized to talk to low level U2F code and using those transfer protocols. It's request second factor authentication with a device. And lastly we have relying party, which stores public key, key handles and certificates and talks to the FIDO client using JavaScript API, obviously requesting second factor authentication. But we need to go deeper. So we're gonna talk about how we can cook our own secure second factor in five and a half steps. So we start with challenge response. Relying party generates a challenge which can transfer to the client. Client that takes those challenge and gives it to U2F device. U2F device using private key performs cryptographic signature of the challenge and returns the signature to the relying party. This way relying party already know the public key. So knowing the public key, signature and original data, it can verify that this signature is valid and this way performs second factor authentication. But there is a still issue with the scheme. If I'm an attacker, I can simply steal the challenge, request signature myself, get the signature and give it to them relying party and will be authenticated as well. So it's not phishing proof. In order to mitigate that, we add another two parameters. Origin and channel ID. Origin is pretty much a URL that you came from. And channel ID is a part of the TLS channel ID extension, which I'll talk a bit more later. So U2F device performs signature over the data and returns it to relying party. Relying party then verifies this data and the user gets phished. For instance, user would go to google.com. And instead of that, he will go to google.com with one instead of L. This way, the signature will be for Google with one instead of L. And relying party will be able to detect that and obviously refuse to authenticate the user. This is awesome. Finally, have a protocol that phishing proof, but there is a still issue with privacy. Currently, we use the same key pair for every single signature. And this is obviously quite privacy issue. If you register on two different sites and their public keys got leaked, then you'll be able to say use this site and this site. And this happens to be in our society. We have some sites that are not exactly publicly acceptable, which would have obviously major issues to your privacy. So to do so, we introduce two more parameters, handle and application ID. So application ID is just a way to identify which application you use. For instance, it can be simple as google.com. And there's a handle. Handle is just randomly generated ID that just identifies a key pair. These two parameters get given to the client, as we can see here. And you have device using these two parameters generate a unique key pair for every single registration. This is why I think this should be called actually registration-specific key pair. So in using this unique key pair, it performs cryptographic signature and returns it to the server. The cool part about that is that if you, that means that you can use one UTF device. For instance, for your and your partner's account and the line party will be able to tell that you actually do so. Because the key pair are unique. So since UTF is open protocol, there's many implementations can be. And some of them may be not secure. So and if they're not secure, that means they possibly can be cloned. So we need to some way to detect if the UTF is being cloned. And we can do so by introducing a counter. Counter increases by one every time cryptographic operation being performed, cryptographic signature being creative. This counter being sent to relying party. And relying party then stores the counter in a database. If you perform a cryptographic signature and your counter values suddenly being lower than the previous signature, that means your device being cloned. Lastly is that we need some way to identify if device is secure. Because as I said, UTF is open protocol. Anyone can do implementation in any way, software and hardware. And we need some way to say if the device is secure or not. So to do so, we introduce, I think, attestation certificates. So the vendor who creates devices generates the batch certificate that installs on about every 100,000 devices. Public if the certificate being published in public available database with description of the devices. UTF device together with just perform actual signature with unique key pair, it performs signature with attestation certificate and returns it to relying party. This way, relying party can take a public key from the certificate, look in the public directory and say if the device is secure or not. And this is probably not usable for Facebook or for websites about the cats. But it will be pretty useful for banks who would probably want to enforce usage, for instance, on the hardware devices, on the certified devices, etc. And lastly is we need to think about protecting our device against malware. So if there is a chance that your computer being infected with malicious software, it may try to do key exercise. It may try to do brute force attacks or side channel attacks to try to recover master key or key pairs that stored in database of your device. So in order to mitigate that, we need to check if the user is present when the cryptographic operation is being performed. And we can do so by demanding to perform user gesture, which can be like pressing a button or like fingerprint or like writing a scan or like pin code or like some group of scope or remembering your wife's birthday. So anything you want, in reality. So we talked at this stage only about services was wide and identify. So, you know, like just Google, but they but different services can have multiple ways to access them, like Gmail, you can access through the web client or Android application or iOS. And they all will have different IDs. For instance, for web, it will be mail.google.com, for Android to probably be hash of the application key and for iOS, there will be bundle ID. So how do we deal with that? Well, we introduced thing called application facets. What pretty much you do is that you set up as your application ID adjacent file. So instead of Google.com, you'll be like Google slash facets to Jason. And here we list which subdomains are allowed to perform second factor application, which Android applications or iOS bundle ID or iOS applications with such bundle IDs. Application facets must be served over valid HTTPS. That means that if you're planning to develop an application that supports U2F in multiple facets, you have to have get proper certificate and it's not going to work with self-sign certificate. So U2F is just a protocol. So we can have a different implementations in hardware. So here we can see, for instance, UB Keys, KeyDo, FastFyDo, and this device, which I keep forgetting the name of, which actually uses a fingerprint as a user gesture. And they all have secure elements and they'll perform all the cryptographic operations inside those elements. And software implementations. So here's a couple of, this is actually U2F0, which I'll talk about later. So we utilize this software to perform all the cryptographic operations. And here we can see actually a Java card that supports FIDER U2F. Now, I do understand that this does not look like a software. But so in the protocol, in the specification, we say that we'd want to have a software solutions, like browser plugins or Android applications. But the ecosystem is fairly fresh and there's no such solutions exist at this stage. So I can't show anything. Oh, by the way, some of the making really nice earrings as well. Sorry. So current users include companies like Dropbox, Google, GitHub, and even Government UK, who just recently moved to U2F as main second factor authentication solution. Browser support. Firstly, Chrome, yes, it supports natively since 2014. It just did a JavaScript polyfill, a bit pain, but fine. You still need a plugin for Firefox, but it's in active development. So at this stage, U2F API has been developed, and the only issue is to implement USB HED stack support for the Firefox. Edge does not, but it supports Web Authent. And I'm sure as soon as they will fully support that, Edge will have to do something about it. And Safari. What's U2F? So there is a new standard coming out for secure JavaScript API for access management and authentication in the browser called Web Authent, developed by, again, Fight Alliance. And Edge is the first to support, which is absolutely amazing, which actually uses things like hard authentication tokens, et cetera. So we learned today. Passwords are hard. Second factor authentication sucks, and we're willing to do something about that. You'd have a sweet protocol skewed. You can do multiple identities and existing solutions and people to actually use it. So let's do some demo. So I'll show you this website later. Jesus Christ. So here's a demo that I've written in Flask. And we're just going to simply register our new account. I'm not going to call it demo. And so we just registered. So we don't have any U2F devices to register within our account. So we just insert the device, press Add Device. It's going to start to blink. Press OK. Done. It's added. We can add another device if we want. It's a demo. I have to do something cool. Cool. So if we'll look at our facets, we can here U2F or secure humanity. So let's go to secure and try to log in. Oh, oh, what? I can just type demo. It's so secure that I think I, oh my god. OK, if I mistyped that, they'll be totally terrible for me. OK, I'll do one key to step. I didn't spill enough blood to the gods of the demos today, sorry. OK, it's waiting for my action. It doesn't allow me to log in. Tap the button, boom, authenticated. Some of the security considerations you have to keep in mind if you're planning to use U2F. You must use HTTPS. And it's not just because if you don't use HTTPS, you probably don't give a damn about using security. But the fact is that U2F JavaScript API would only be supported for secure browsers. Secure site, sorry. Start using TLS channel, try to play with it. It's not fully standardized yet. TLS channel ID, that will help you to mitigate in the middle of text, session reuse attacks, and will improve accessibility of your sessions. U2F is your second factor. Please don't use it as a primary factor, like some people have seen do. There's a couple of things to play. So there is a Python U2F libraries from Ubico and Palm U2F. They might be not the best way to start to use U2F, because you need to understand the protocol and read a bit of specification. So there is my FlaskFighter U2F library that actually used in the demo that you've seen before. And there is a Django U2F, and I'm making my own Django library as well. There is a Google's U2F reference code. They have reference Java implementations, some of the JavaScript stuff, and some of the other documentation. There is U2F0, which is pretty much how to make your DAY U2F token. And there's my demo that I said before. There are specs and data. I do really encourage to use developers to Ubico.com for specs. They've done a really good job into properly describe U2F. Obviously, I read official specification on FIDERLINE's website. There is Ledger HQ, which Ledger HQ is actually a company who makes Bitcoin wallets. But they use U2F for all their authentication. And they have Java card implementation of FIDER U2F. And there is a FIDERDEF mailing list, where a lot of nice people like me always happy to help you. So what's next? We need developers. We need people play with the U2F, test U2F, try U2F, integrate U2F, make more things to play with. Boom. The U2F is really amazing protocol and might finally solve our problems with secure authentication. So we need to grow our system. So do it. So special thanks to Ruth McDavitt and John Clegg and Summer of Tech for all their help with mentoring and testing and listening to me, et cetera. Thanks to Tom Eastman, who was supposed to introduce me, but he got really stuck with his stuff, for encouraging me to do the stock. Thanks to Mitchell Harmon for listening to the stock for six and a half times while I was practicing it. He's actually there. And thank you, organizers. Thank you, sponsors. And thank you all for coming. Your guys are really awesome. Major thanks to Yubico for sponsoring me. They were not afraid to sponsor some random guy from New Zealand to come and talk about U2F. And they actually have done nothing with my slides. It's like I had to come up with all this stuff and advertisement. Questions? Hey, thank you for that. So what's the user flow like if you lose this USB key and now you're locked out of all your sites? General advice, pretty much, to have multiple keys registered. Thing is, we had discussion actually with Mitchell yesterday night. If you lose U2F key, there is no way to trace back from U2F key, absolutely. So it's been pretty much, if you actually lose U2F key, you make someone stay good, because they finally have a good way to secure their accounts. So yeah, there is no information would be leaked, especially if you would have questions about how do they generate the keys. And you can ask me. Yeah, so have multiple devices do the best solution. Thanks. What do you think about the Google prompt notification two-step verification thing they recently released? It's a biometric one, right? And it's a pretty much push notification to your phone. And you just press yes or no, if you want to log in. Oh, that thing. Probably better solution than nothing, since you have actually have to steal someone's phone in order to protect it. I haven't actually looked in the law level how the protocol works. But that's better than OTP, and it's better than nothing, I would say. Any other questions? Yes, on the side. I was curious about the cloning prevention. There's a counter there. Is there anything to prevent, say, the clone device from increasing the counter until it looks like the original device? No. I mean, this is some solutions that you can probably implement on the back end. So you may be checked that if suddenly there is a lot of tries of the counter, you may be like, lock the account, or disable this key, or whatever other solution. But no, no others. You mentioned phishing protection by adding a couple of additional information to the challenge. Does the counter prevent replay attacks? Yes. Yes, it would, because you store the counter on the server, and it means that you will try to do a replay attack. The counter value would be lower than the last signature, or the same as the last signature, and this way you'll not be able to authenticate. Any other questions? We've got time for maybe one. Do you have more questions? Do you guys want to see how do you generate the keys? Just quickly think that some people might be interested if they're going to think. One more minute. OK. So we have two ways to generate the key pairs. We have non-wrapping and wrapping. So here is a non-wrapping way. So you get just simply get an application idea, use random generator to generate the key pair. You store the key pair in a secure database, and you give it to a lying party. Cool stuff. You always have a unique key pair that nobody ever will be able to predict. But bad stuff, you have to store it in database. Your database have to be secure. Device will be expensive. And this is how Kido does the stuff. This is how Ubicode does the stuff. So we generate a random key handle, which is nonce and a Mac. And so we take application ID. We merge it together with nonce through HMAC and wrap it up with device secret. Generate the key pair, throw off public key, perform the signature bundled together and return to lying party. And we generate Mac by taking private key and again application ID and wrap it up with device secret. This is cool. You need no memory on the device. But you have a device secret. So you have to trust your vendor, obviously, that he will not leak this private secret to some nice agencies like NSA or FBI or FSB or any other stuff. So yeah, so this most things described pretty well in the protocol. And I thought it would be interesting to talk about. Could you please join me in thanking Yuri?