 Hi everybody, it's my first time here, so I'm sorry for the English. One of these days, I would be quite comfortable presenting in French, but today, it's in English. We'll talk about what is OAuth, OAuth, OAuth, it's been pronounced many times. We'll talk about what is HOTP, or how is it from TOTP? We'll talk about what's TOTP suggest, raison d'être. Why not just use Pam OAuth or Pam Google Authenticator or many other things? Why not use Duo, Ubisoft, Linux, OTP, et cetera? And we'll talk about the main goals. So, I've been a programmer since 1995, which is not a very long time. I used to work for McGill. I was head of the web group at McGill University. I was a Python programmer since 2002. I'm a Linux administrator since 1998. I worked at the University of Physics and I co-wrote YUM. Well, I co-wrote, I helped out with the creation of YUM. I'm part of the Linux Foundation IT team. I've been working at Linux Foundation since 2011 in November. The main reason why they hired me is because I used to work for IT security at McGill University and after sad events of September 2011, they were looking for somebody with a bit more security expertise to join the Linux Foundation team. And I'm interested in web and Linux security and I'm also interested in social engineering. For example, if you have a Russian name and you speak with a heavy Russian accent that they present on security topics, people think you are actually much better than you are. So, I don't use it very often because actually, most of my adult life has been in the U.S. and Canada. So, what is oath? O-A-T-H, not to be confused with O-A-U-T-H, which is something completely entirely separate. O-Oath stands for Open Standard for Authentication with an N. O-A-U-T-H stands for Open Standard for Authorization. I'd like those two people to meet and to beat each other because it's very confusing for everybody, not just for you and me. So, we'll talk about the oath without the U, about the authentication. So, oath is a bunch of people who gather together. It's like more than 30 companies from Microsoft, Google, everybody else. They put together a standard for one-time passwords. So, one-time password, the benefit of one-time password is, how many of you have here used two-step verification with Google? Should be much, many more hands, by the way. So, it's basically the mechanism behind it. The parent standard is H-O-T-P. It's counter-based. So, it takes a shared secret between your phone and the Google server. And it uses H-MAC procedure to calculate a string. And then it takes a subset of that string and turns it into a six-digit code. And that's basically how, when you send that code, the server does the same calculation, same H-MAC procedure, take subset, turn it into a six-digit code. If those codes are the same, that's how it knows that you have the device with the same pre-shared secret. T-O-T-P is a subset of it. It's instead of taking a counter. So, with H-O-T-P, every time you authenticate, the server increments the counter by one and your client increments the counter by one. If you press the button too many times, you basically lock yourself out. So, because there's a window of good numbers, usually about 20 to 30, if you've pressed that button more than 30 times and you didn't manage to authenticate during that period, the server will just stop validating you because of the window. It went far beyond the window. So, it's bad for Google who doesn't want to be on the phone with clients, saying, can you please re-resync my counter with your servers? So, the subset of H-O-T-P is T-O-T-P, which is time-based. So, it basically takes the current timestamp from 1970. Everybody knows that's the good time. And it uses that instead of the counter. So, it increments every 30 seconds. If you've ever used the Google Authenticator, you'll notice that it's after 30 seconds of changes. The digits that are on the output on your screen are impossible to, well, impossible, take that with a grain of salt. It should not be possible to use any number of them in any succession to figure out what the actual pre-shared secret is between your server and your device. There's a wide support in hardware and software. There's Google2Step, uses T-O-T-P. Facebook, uses Facebook Verify, also has six digits, uses T-O-T-P. Microsoft even uses T-O-T-P. There is H-O-T-P, uses the number of devices. UB Keys, if you've ever seen them, they're cute little devices. They're like this. They plug it into your laptop. And there's one big button on it that you press and it actually acts like a keyboard and sends a set of keystrokes, which is really clever, I think. It's supported there. So, why did we write T-O-T-P-C-G-I? It's basically, actually it's pronounced 2-PC-G-I after 2-P and B-N-O. Don't ask. The T-O-T-P-C-G-I is back two years ago when we wrote it. There was no fully free oath implementation. There actually still isn't really. It's either non-free or non-libro or frequently both. It cannot be securely used across multiple systems. I'll talk about it in a bit later. There is Duo Security, which is the many people that actually used. It's cloud-based. You put all your eggs in the cloud basket there. It's non-free. There's 10 users that's free. Then you start paying prices. It doesn't scale very much, obviously, if you have over 100 users. There are a number of standalone PAM modules. Some of you may have investigated. There's a PAM Google Authenticator, which was the game in town two years ago when I started writing it. And PAM Google Authenticator is neat, but it cannot be used securely in multiple systems. So the OTP part and the TOTP stands for one-time password. So if you can take the same digit and reuse it in a different server, that breaks the standard. So if you have PAM Google Authenticator installed in server one and server two, and they have shared the same secret in both of them, an attacker can listen for you to authenticate to server one, then reuse the same code in server two because they don't communicate with each other. They don't actually have any idea that server two doesn't know that this isn't really used once in server one. There are a number of ways you can sort of game the system. You could put your secrets on the NFS partition, but don't do that because it travels over the network in clear text, which is even worse. They don't have any provisioning. You can provision Google Authenticator from command line, but it's basically it. So our core goals were to write a server that will solve the problem. That will be free forever. That's open source. It's Linux Foundation. That is open. That is pure Python, excluding some of the crypto-lips that are non-essential features of it. It's simple. A lot of people get hung up on the CGI part and said, what is it, 1990? Well, the CGI is very fast. It is very simple, very well understood. The core of the entire library, the code that you call when you authenticate, when you submit that signature code, fits in 900 lines of code, including comments. So it's extremely simple. There is a very, very small surface of attack. Surface of attack is an important aspect of the security library. Somebody actually asked me, why didn't you just write it in Django? And I just kind of laughed. We gave it a lot of thought about the security. It runs as unprivileged user. That's another benefit of CGI. It can actually transition into its own SELINX context. It relies on mutual server client TLS authentication. We can complain about TLS and open a cell and all those things all day long, but we still don't have anything better, unfortunately. So when the client communicates with the server, both the client and the server mutually authenticate. So an attacker will need to first even steal your certificates and the key before they can actually even get to the application. So the features of TPCGI are we have full TOTP support. We have provisioning CGI, which I'll showcase in a moment. We have a QR based enrollment, all the good things. We have HOTP support for UB keys. We have free radius support because it's been requested so many times. We just wrote it free radius. That's pretty much still the only game in town. It was written in the early 90s. It uses pre-shared secret. That is one for all clients and for the server. So if one client is compromised, you basically have to redo your entire thing. Free radius is really horrible, but everybody still uses it. So we are going to have to write the way to hook TPCGI into free radius. There's LDAP integration. So you can do, you know, have you ever used the secure IDs? And you also type the password, then you type in the six digit code and you can do the same thing with TPCGI. It will check your password with LDAP or any other thing. And it will check your code, then code separately. And there is a fast TGI mode. So if TPCGI is fast, you can write it in fast TGI. It's even faster. It scales really well. It can run behind a load balancer with a few caveats. You have to use a DB database storage backend for this. The default backend is file. You cannot use file backend, sanely, between two members of the cluster. We are working on a potentially MongoDB backend. There are a couple of testing we need to do to make sure we can do it securely. There are a number of things we do to make sure that the one time really always stays one time. So we have to rely on locking quite a bit. There is no locking in MongoDB per se. Because we really want to scale it up. If you have thousands of clients authenticating at the same time, you want to make sure that any one cluster can fail at any time but without it impacting anything. And you can already do it with a database storage backend. The state files that are written per user are actually JSON. So a JSON store that is master-master replication actually is an excellent idea. So we just want to make sure that we can rely on... We can work around the lack of locking in MongoDB. Actually, any JSON distributed server lacks locking for good reasons but bad reasons for me. We'll see. It's not there yet. We'll work on it. So any questions on this before I get to the lab?