Europe, Django and two-factor authentication

Speaker 1: Hello. So we are about at the end of the third day of Torox. Everyone is tired. I am at least. And apparently I have a very relaxing voice. Which is an interesting combination for a nap. So as a precaution, I decided to begin my talk with my conclusion. So should you need to take a nap, you still get the general idea So yes, please add MFA on your app

Speaker 1: and or strong code authentication. Impose strong authentication to administrators, that is, users who can access a lot of personal data. Propose it to other users as an option. Technically, there is no difficulty to add MFA on a Django app and on any web app in most usual languages whatsoever. But You should pay special attention to user experience because this is where you will likely spend most of the time, and it's okay

Speaker 1: So, end of the conclusion. You can nap if you need. Now I will move to the introduction. So um let me introduce myself. My name is Agnes. I've been a web developer for 15 years, full stack. But I'm relatively new to Python and Django because it's only been four years or already four years. I'm currently working for a cooperative company named Hashbang , which is in Lyon, France. I think you have heard this. My clients are mainly the public sector and associations, non-profits. And oddly enough, my primary expertise is not

Speaker 1: security, it's accessibility. which is how I got the public sector but they happened to handle sensitive personal data and therefore they had requests regalant security which is why I'm here today. This is where my knowledge comes from. It's mostly from experience. I also happen to have children. One of them is here. And the other one uh draw me like this So this is uh an expression I use often when I do accessibility audits.

Speaker 1: This is the face. And when I talk about personal data leaks too, um it's my first Django con and it's my first time in Ireland too Which made quite an impression of me and on my daughter who made This piece of art. Uh I'm also a member of uh French Python Association. And we also have a PyCon in France, which is coming in Lyon

Speaker 1: at the end of October. So two days of talk, two days of sprints, then two days of talks. We have good food. We have good people. I cannot guarantee the weather since it will be on the November the first. So now back to my talk. This is the the structure. First, I will explain what I'm talking about. So we are all on the same page and I like uh go back to basics. Then I will explain why I'm not talking of everything Next, I'll try to give you a basic understanding of how it works.

Speaker 1: So you can understand the error messages. that's your third package third party package uh displays and finally I will share my personal experience uh regarding MFA on Django Are you ready? Let's go. Uh so the first part with the definitions What is identification? Identification is telling who I am. I am Céline Dion. So you notice I can tell everything. Authentication is proving who I am. How can I do to prove my

Speaker 1: identification to a computer? Uh means of proving who I am are called authentication factors. There are three types of factor. Knowledge factor, inherence factor, and possession factor. The most usual authentication factor on the web is the knowledge factor. It's a password authentication. Everyone knows that Inherence factor are also called biometric factors. It's a fingerprint scan or the face ID, for example. These are mostly weak on their own So uh I don't I won't talk about them a lot, but a little bit anyway.

Speaker 1: And position factors Are physical objects that you can carry with you and which contain a cryptographic key. Then it's a device which authenticates you with your service. So this for example is an authentication factor of uh with a position vector And MFA, multifactor authentication, uses at least two different types of factor For example, a password with a TUTP challenge, it's knowledge factor and possession factor. A pass key or a UB key unlocked with your fingerprint

Speaker 1: is a position factor with an inherent factor. So these are MFA. It's not the same thing as strong authentication, which is at least one strong factor. If you sum up a lot, that means there is a big key or there is a key that's difficult to break. For example, pass keys are strong authentication because of the underlying protocol. So We have the basics. That's cool. Let's talk about the context. Who should worry about

Speaker 1: authentication, about MFA? You should worry about MFA and before someone asks you to, because it will probably be too late. Um why should you worry about security in general? Is it to protect your employer from reputational loss? Is it for you to keep your job? That's valid reasons, but I give you another reason. Have you ever heard of the general data protection regulation? Yes. Who loves it?

Speaker 1: Oh. I don't like cookie banners, but uh GDPR is not about cookie banners. Who has already read the GDPR? Oh that cool. All of it? Because I didn't read all of it. Grammatically it's a bit challenging at least. So here I put the article 32. Uh what I can recommend is you read at least the article five, which is a summary, and the article thirty-two is here about security. So what it does say

Speaker 1: is that security is a legal requirement. It's an obligation. And why is so? It's to protect People, natural persons, it's people, it's not employers , it's to protect freedoms and rights of people. how you do so by ensuring a level of security appropriate to the risk. What are the risks? A risk, it's a combination of a probability and an impact. And when we talk about

Speaker 1: personal data leaks Probability is very high and impact is high too. Uh probability I won't Uh well, you know howaminpound. com. It's uh hot topic. Uh but when you have s uh just usual data such as name, birth date Postal address, it can be a very sensitive topic for some people who are at risk on political level, for example. Here you have a screenshot of a press article

Speaker 1: which I took uh last summer. about the threats on uh some lawyers and it didn't get better since So what I would like you to remember is that data safety means people's safety. And this is what the GDPR is truly about. It's not about uh cookie banners. It's uh letting people 's identity uh into the wild is dangerous for them So it's not just a legal obligation, it's ethics. So could we please, as a profession

Speaker 1: Be a little more um attentive on this. Yes, we can. Not like the Caisse nationale d'assurance vieillesse, which is a French retirement fund. They were stolen a bunch of data. But it was no big deal because uh no bank details were stolen. And they apologized, so it was cool. Um I can easily change my bank details if I need to. It's more difficult to change my physical address and I cannot change my birth date, not

Speaker 1: legally anyway. So you see in a way every personal data is sensitive And the interesting part is in the middle, most of the time personal data these days is stolen using a privileged account. like the one of an administrator or the user a companion tool. Big database leaks are not big thing anymore because we have evolved into more security on this point of view. So to sum up the second part, the most valuable thing in your database is people's data.

Speaker 1: They have entrusted to you, they trust you. Be worthy of it or get rid of it. So the shared recommendation is to enforce strong authentication, not double, strong. For everyone who can access this massive personal data. That means administrators, employees, service providers, accountants uh maybe interns and so on. This does not exempt you from other security measures, but I'd only have 25 minutes. And offer MFA to other

Speaker 1: internet users as an option, particularly if you have bank data or sensitive data. Cool. Then I'm going to talk a bit about technical aspects. How do they work, these position factors? I like to go back to basics as as I explained. So there are two main strategies, either a shared secret Between the device and the server, and this is called a shared secret or symmetrical cryptography. Or we use a private public key pair and we call this a symmetric cryptography

Speaker 1: because each of these two keys will have a different role in the process. First, about symmetrical authentication. I'm only going to talk about the TOTP algorithm, which is the most common nowadays. So have you ever seen this kind of interface on a smartphone? Cool. Did you know it works on airplane mode too? Good. And did you know you can make it work on this kind of device who has absolutely no connection to the internet? It works. Magic Maths. So how does it work?

Speaker 1: I call this the eyebrow algorithm because it's based on a shared secret. Someone is already laughing. When you share a secret with someone, you don't want anyone to hear it, so you make in windows and you move your eyebrows like this I know you know. See how does it work? At the beginning when you activate MFA, the server generates a random key and shares it with the client device Then the day the human wants to authenticate the device does the following. This joke is too big for me and it's not designed. So first it concatenates the key with the number of minutes since the beginning of time, which is in

Speaker 1: 1970. It hashes the result with Shay1. Scat is here for a pun on which I haven't found a suitable translation. So there are not a lot of French people here. And in the end, the hash is turned into a six-digit code in a deterministic way. Several does the same calculation inside. If the end result is the same, authentication is validated, I'm the one. I can go. In reality, it's a bit more complicated, but having the basic idea, like I presented it, you can understand the more precise options

Speaker 1: you can set in a real-world example. Here, for example, a screenshot of a TOTP device config in Django Admin, which shows that in fact it's not a minute, but it's a step here of 30 seconds The origin of time can be set, the number of digits, and so on. And if you think about it a little bit. If the device is not on time, it doesn't work. So there is a drift. And this kind of Device kind of struggle to stay on time. So we had a customized view to activate

Speaker 1: the device On the first authentication, we added a huge tolerance just to detect the actual drift. And then we had the drift, so we set back the torrents to one or two. And uh I couldn't have done it if I didn't understand the underlying basic protocol. So it was fun. I may have a weird uh version of fun, but it was fun anyway. So let's talk about asymmetric cryptography You I assume you have heard of public

Speaker 1: key and private key. Yes. Oh, my notes are in French. That would be interesting. So um the basic principle of asymmetric cryptography is that If you encrypt something with a private key, you can only decrypt it with the corresponding public key. And if you encrypt something with a public key, you can only decrypt it with private corresponding key. So uh the first use case is to sign messages. It's an authentication method. Can you see where I'm coming? And the

Speaker 1: reverse is to ensure that the message is confidential. But now I'm just talking about sign message. So how does it work in Webuton? In YubiKey, in a pass key So it's a star and the fanboy algorithm. So it's a signature. At the beginning of the story The client generates a public and a private key, and it shares a public key with the server. Then the day

Speaker 1: the human wants to authenticate, what happens? So imagine the device is a star. And uh service is a huge fan of this star. So when the star wants to come in The fanboy says, It's you. Oh my! I love you. Can you please sign me an autograph, please? And this photo of my dog And so the star says Yes of course here is another

Speaker 1: And it's a sign message. So the the server decrypts and if it finds The dog photography. It's okay the authentication works So now we'll you will think about sunglasses and dogs every time you use your YubiKey, and this is my goal in life So this is what the idea of symmetric authentication. So it's funny. But in real life You don't need to know much more about

Speaker 1: authentication methods in crypto and in security in general. We avoid homemade solution, not like this banana bread, which is trying to to evade some sort. We are very proud of the banana spread code name. So um back to computer security, yeah. So in that case you should reuse libraries coded with people who know how to do it and who have checked it's secure with the open source process in the the interval. You don't reinvent the wheel

Speaker 1: In security, this is really crucial. There is much more to lose than just time. Okay? Yeah, good photo. I like it. So, um now for the last part, the real life. How do you set up MFA on a real-life Django application? It's very easy because it's Django. And it's very difficult at the same time because it's reality. So in real life, I use the package Django Two Factor Oath, which is complete. It deals with symmetric and asymmetric authentication. And uh as well as less robust authentication such as email

Speaker 1: or text messages, but avoid text. Email is quite okay, I guess. So it's really very easy to install. The doc is complete and it just works. You need to plug out the existing login routes. So it can be a bit longer, but not that much. But It looks like this when it comes out of the box. So uh sooner someone said Graturix is speed, clarity and design. We don't have clarity, we don't have design. Uh clarity isn't here because of technical jargon.

Speaker 1: It's not just because it's French. Even for us French speaking, it's Not good. I don't know. Do you English speaker? Do you use the word token to speak of a six-digit code? Yes, for real. Okay, because in French no one uses the word jeton. And the this module is perfect. And I just Get how I can retranslate it better. But even the word authentication, authentication in French can scare some users. Uh

Speaker 1: here is the same package uh login from side. Usually I have to make it uh fit the design of my customer and sometimes I also have to make it fit the wording. So a piece of advice here I was given when I was a baby Django developer. It was write dumb tests to avoid dumb bugs. And here I didn't write dump test because it was not my it wasn't my code. So I thought I didn't need to write test My client just asked to change the wording from username to email.

Speaker 1: Then I just introduced a very subtle bug. In the template, and it didn't go very well on production. So now I have a dump test that just logs in a user from this form with MFA and without MFA, just to avoid bad moments like I had on this uh embarrassing episode. And this is another real life example. the service which provided these cards. What I found it very interesting is that they use the word um code temporaire in French temporary code

Speaker 1: in English and I like it because it's not frightening for non-technical users. And it has the idea of this code is not long lived. So this was the the idea of our designer and it was a great test and a great one. Yep. It's already time to conclude, even if you already know the conclusion. So yes please add stronger authentication

Speaker 1: uh mostly for administrator because you want to protect personal data, propose it to others, and technically no problem, but UX is a thing. Thank you.

Speaker 2: Yes, thank you. Wonderful talk. Um uh strong authentication.

Speaker 1: Yes.

Speaker 2: Is it just pass keys or Uh there are other options.

Speaker 1: TOTP is okay too, yeah. Because uh you have a big key for the moment. It doesn't hurt to stay up to date with what is the definition of strong authentication. For example, on asymmetrical cryptography It depends on the algorithm used to generate the keys. No, you should use ED something because I don't remember any number uh and you shouldn't use RSA anymore, for example.

Speaker 2: Thank you.

Speaker 3: Thank you for the talk. Um I saw that you you have this example of an actual physical card So how do you get the private key on the card or vice versa?

Speaker 1: Um the provider of the card sends us a CSV in an encrypted very sensitive way because it's like a whole bunch of passwords in clear. And uh when the user first authenticates we ask them the serial number on the back so we can uh create the actual authenticating device in the database in that moment.

Speaker 3: All right, thank you.

Speaker 4: When you use uh one-time tokens, how do you mitigate um man-in-the-middle attacks?

Speaker 1: Uh with HTTPS at least. Um yeah, that's a good question. It's I think the TOTP protocol is mostly it relies on the shortness of the password of the token. So you shouldn't make them live more than one minute for example. Usually it's 30 minutes. Uh 30 seconds, not thirty minutes. Absolutely. Never. Please. So um you would need uh a very quick man-in-the-middle attack

Speaker 1: and uh or high tolerance. So basically that's why I said TOTP is okay for the moment, but you should stay up to date. For me there is a vulnerability here on the length of the password. Pass key as good are good anyway. I think it's uh the the future of strong authentication. Is it okay? Well He 's not satisfied. Yeah, it's not perfect.

Speaker 5: Thank you for the talk. Uh I did not fall asleep. I had a question about the drift, the time drift that you mentioned. I think typically that's something that is encountered on the client. But we've we've uh encountered an ISP who will um occasionally block uh UDP traffic and the NTP server will fall behind. And so the server's reference for the OTP gets off and then no one can log in. I wonder if you have any recommendations for handling This situation, um another factor, maybe a pesky, I'm I'm not sure. Thanks.

Speaker 1: Well about the drift we had two main problems for people who use the smartphone Some of them were not on time, so we we fixed the problem by phoning them. To make them configure correctly the time zone on the smartphone. And uh for these things uh we noticed early in the process that some of the cards had an already existing drift when the customer uh when the user received them And they tended to drift uh more and more

Speaker 1: as time passed. So we added uh we had a tolerance of two So or one, I don't remember, to get the the little drift increasing uh by small steps. So we we managed that by adding a little tolerance. to to get the and I think it's a shared recommendation to add a little tolerance on OTP tokens because humans are human and there is a network delay as you said. Thanks.

Speaker 6: Thank you.

Speaker 1: Thank you.