 I just want to introduce Robert Hewitt, he's been a music contributor since the last millennium and he's been speaking in the Muslim room in all four stands except one. He's a fan of Star Trek, space exploration, science, Linux and other open source software, American football and country music. Please welcome Robert. Hi everyone, did you want to see some? Hi everyone, as Alex said, I'm Robert Kaiser, Muslim called Cairo. I'm talking about web logins after persona or how I solve the problem at least on my small websites. So one question for the room here, who in here does not know persona? Okay, there are a few, so I'll give it a quick recap. Which persona is a good question, because Mozilla use persona for multiple things. But the persona login solution was an identity or login solution operated by Mozilla. It ran from 2011 until the end of 2016, turned off now. That's why I had to find a solution. It's a decentralized solution or it was a decentralized solution or a federated solution, which had a central fallback to a central login provider at Mozilla. You could use multiple identities, that means you could have some different identities stored in the system and you could log into websites using those different identities. As identities we used email addresses, so it was verified email. The persona service verified that the email belongs to you and then it sent this email as your identification to the web server. It had some potential for browser integration, even though that was never done. And the browser ID protocol that it used was easy to implement for website operators. And it was permission less, so websites implementing it did not need to actually ask for permission to use it. There's more information about the background on François André's blog. I linked it in the slides. I didn't say that in the beginning. You saw the URL of the slides in the beginning. It's on slides.kyro with a K.AT. Just the first entry there, it was in 2017. So you can actually find that and click all the links afterwards as well. So persona was going away. So a small website, if it needs some administration or some dynamic component dependent on users, which I had, I was writing a content management system or I'm operating a content management system and some other websites that have states that need to be edited. And so you need to log in for that. What do you need as a small website? It needs to be easy to implement as a website operator. You need to have to trust the identification that you get from those logins. You really want to avoid dealing with storing passwords because everything can go wrong there. My old system stored passwords basically as plaintext and sent them as plaintext via email to users. So basically all the mistakes you should never do. You really don't want to care about how to store passwords yourself. You want to have some solution that's proven to work. And that's upgradable, by the way, if newer standards come out for that. You don't want to be locked in. So if one authentication or identification provider goes away, you want to be able to still communicate with your users and switch to something else. The good thing with Persona was, as it used email for identification to websites, you still had this email that you can use to communicate to users. A lot of other login systems use emails as well, so you can actually identify the same user by coming to you with the same email even through a different login system. And ideally you want privacy. Ideally you don't want to tell some third party who is logging into your websites when... because then they can watch basically everything that's happening on your website. So you really want to avoid that if possible. So what solutions do we have? I started to think, what can I do for my websites? Basically two things. I can do everything locally inside my website system, or I can have it done externally. For doing it locally, it sounds easy to implement, but as I said you want to avoid storing passwords. You need to find out how to communicate some verification codes to users and things like that. The devil is in the details there. It sounds easy to just have a password and username, but the devil comes in the details. The good thing with the local system is it can always be trusted. Because as a website operator you probably have to trust yourself anyhow. And the bad thing is, as I said, it needs to secure passwords. You need to care about that yourself, write code for that yourself, and that's error prone. And potentially hackable if you don't care exactly what you're doing. The external providers have the potential for logging. As I said, you may need to use that provider for the rest of the life of your website. If you don't have any identifiers of your users that you can use to communicate directly with them. There's potential privacy issues. As I said, you're telling those external providers when people are logging in. And the implementation difficulties is different depending on what you use. It could be very easy if they provide even some code on how you handle it. It could be very difficult if the API to use it is very difficult. So, which external providers do we have? Local is pretty easy. I have to write the code myself. Which external ones do we have? So Mozilla persona has gone away. Firefox accounts sounds nice, but it's not usable for anyone outside of Mozilla. So it falls out of that as well. So you end up with a number of the players you probably know from some websites, like Facebook, Google, GitHub, and so on. You see a collection of icons up there. A lot of people call that the NASCAR login, because it looks like the NASCAR logo you see there. With all these different colors. So that's maybe having all those buttons up is probably not the right solution as well. There's a number of other OAuth 2 providers or OpenID Connect providers. OpenID Connect is a standard for logins that's based on OAuth 2, which is an authentication protocol that's pretty common now. And there's also other providers or standards like OAuth 1, like a number of smaller ones that didn't take off that much, but mainly nowadays you see OAuth 2 and OpenID Connect. And of course, there's the potential of intermediates. Just mentioning those because Mozilla is using OAuth 0 for some things that's an intermediate, it provides you all the code for handling the login from your site to them. And then they are talking to the actual authentication providers. And you can pretty easily configure that. It runs on a proprietary server of theirs. So it's not really the thing I want to advertise on an open source conference, but it's something you can use. But for a small website, you may be able to use something different. But I didn't want to use a proprietary middleman. Small interlude is one external provider or one external system that does not exist yet but is in the works. So it's a future alternative. It may deactivate the auto-distract of persona. It uses email authentication. It's decentralized with a foldback that's not centralized, it uses passwordless email login. It's speaking with OpenID Connect to both the client side and what they call brokers, the identity providers on the different domains out there. And they call it a spiritual successor to Mozilla Persona. There's a number of people who actually worked on Persona working on Portier as well. And it's still in development in early beta. You can find more information at portier.github.io. They will be an interesting alternative once they are in the stable mode, but they were not there yet. And I needed something for my websites right now. So I figured doing everything locally in the website is maybe not the best solution. But I don't trust those big external providers too much and they want privacy from them. So what can I do there? Well, I may be able to just implement the same thing as for an external provider on my website. And then basically with the same protocols talk to something that I still host locally, but at least I have everything encapsulated there. And I call that a local external or self-hosted external alternative. This gives me the full control over the login stack as it all runs on my machines. The password security, I still need to care about it, but it's at least isolated from the website code. And it's code that's hopefully reusable and that other people can look into if it's an open source thing. And we can guarantee that it's a good solution. Management of multiple identities is possible if I write it that way. Privacy and trust are no issues because I don't need privacy from myself. I already know who logs into my website, so I'm not telling that to anyone else. And I hopefully, as I said before, can trust myself. And when I'm using a standard API, like UF2 or OpenID Connect, there's a good possibility if I find out that's not the solution I want in the long run, I can switch it out to some other solution that uses the same protocols because I already have to code for that in the website. The downside is I still need to secure the whole system and the passwords properly. But I thought there's good documentation on how you should do that. I can probably look into that. And this library is already there for handling UF2. So I know PHP. I thought, well, there's libraries for UF2. Let's do something with this. I created the PHP auth server. It's using the UF2 API via this library via UF2 server PHP. It can be extended to OpenID Connect. I didn't do that yet. The password storage right now happens with the PHP standard password hash function, which uses pcrypt, which is good enough, refused with enough iterations, but there's better algorithms out there. I'll report it out there on the PHP bug tracker to actually use something better. We're trying to use sCrypt, but now there's even better algorithm that they propose to use. The good thing is, once they have a better algorithm in PHP, the code is in there to automatically update the security for everyone on login. Because on login, they tell you the password you can re-encrypt with a better function. I'm also using a non-stare that's stored on disk and extends the password of the user. So if someone gets the database, they cannot do brute-force hacking of those passwords easily enough because the non-stare on disk is needed as well. It's relatively easy to install on a lamp system as they called it for a long time, Linux with Apache MySQL PHP up to PHP 7, which I'm using on my local systems when testing it. My server still runs it on PHP 5, but it breaks with both. I'm using a database extraction layer for the database extraction, not all of the doctrine, but just the database extraction layer. So it should be pretty easily extendable to other databases. The PHP utility classes are something I did myself and put on GitHub some time ago. I'm just using that for email and DOM document abstractions because I'm building every HTML document I'm putting out there as a DOM document and only serializing it then, which makes it much easier to not forget and text and stuff like that. It's skim-able to brand the installation for the operator. Mine is branded like you see in the picture up there with my logo, but it comes with a mutual one by default. And my installation at auth.cryo.at scores pretty well on the security tests I could run on most of the observatory, on SSL labs. Some of that is because of the code. Some of that is because of the PHP configuration. The Apache configuration, which I have examples in the repository for. So you can just copy from that if you want to use it. So current status... Oh, that runs off the screen. I thought it would be 3x4 and it's not... Current status is only to support the authorization code flow of auth2 right now which means the website sends a request for authentication. Then you log in there and for normal login, it implicitly grants it if you log in. And it sends back a reply with an access code to the website. On the server side, you request a token for that access code and with that token you can then do something most importantly get the email of the user. So you have a user identificator. The client credentials flow which is a bit less secure and doesn't have this flow over the server in there but that makes it less secure because it only works between the browser and authentication server. That is not supported yet but the library can do it so it should be easy to add the OpenID Connect stuff is also supported by the library so it's just a question of adding it. I only tested with Apache in MySQL or actually MariaDB for now. It should be easy to extend that for other web servers and databases as long as they're supported by the Doctrine Abstraction layer and you can run PHP on them. There's a remaining documentation in the main readme. It supports US English and German as defined by your browser because that's the two languages I know of or that I know how to write in. Testing is right now very rudimentary. It's just I'm trying it with my own document management system and I'm trying it with a secondary system. I'm running that has an independent implementation. I want to give special thanks to Christoph Zahner who did a review for security issues and he didn't find any real security issues. He had a few minor comments that few of them still need to address but most of them was nothing special and the thing that's cut off here is probably the most important thing of this whole slide. It's open-sourced. It's available since today, since a few hours ago at github.com slash kyro.at slash auth server. It's under Missouri Public License too. I care to put a license on my projects unlike many others on github and it's out there right now if you want to use something like that. It's an open-source project so it needs help. By the way, this on the right there is the unbrained version you see by default. The login piece of it, my logo is not in there. It's somewhere in the repository so I just started it without being able to scan it. What needs help there is implementation of especially OpenID Connect. Maybe the client credential flow as well. A test suite and infrastructure to run the tests. More complete documentation. More UI languages would be nice but upper three are probably more important than that but they're still a good thing. It's standard PO files so it's easy to do the translations. More installations out there that actually try it and see how things are working and of course any of your ideas and pull requests for it would be very, very appreciated. That's it. I think we should have time for some questions. The URL on GitHub is here again and if you want to contact me, that's my email address and my Muslimian's URL that actually has the few social metrics I'm on. It has the links for that. And with that, are there any questions? Can you please give me a question? Sure. Yes, Marjul? Would you know? Do you know L-O-E-A-S? I don't know L-O-E-A-S. So the question was if I'm basically running my own OAuth 2 provider with that. Yes. This is an implementation of an OAuth 2 provider. Somewhat incomplete because it doesn't have the client credentials flow. It only has the authorization code flow. But yes, it is one. You say the L-O-E-A-S? I don't know of it. It's a JavaScript library that includes almost all... Okay, so it's something that provides this wall of icons or it can provide it. So it's a provider of OAuth 2 providers for websites. I didn't do anything like that right now. The thought behind this is for people to set up their own provider there. So I don't want my provider to be one that a lot of other people are using. I prefer other people actually using the same module and running their own for their purposes and not telling anyone else who's logging in on their website. But using some common code that can be made secure enough. Was it allowed to use a persona before? So the question is if there's any chance for Mozilla to use Portier. I'm not sure. You would need to ask those people at Mozilla who are implementing sites that are using logins. I think Mozilla probably likes the idea of Portier or a lot of people at Mozilla. Mozilla doesn't have one opinion usually. It's a lot of people. But I think a lot of people like the idea but we will see where it goes when it matures more. Right now it's in a very early testing mode. But I like the idea as well, of course. Any other questions? One of the advantages of persona was that you could log in once and then be logged into a number of websites. Federated login, right? Single sign-on. Do you think that that goal today is incompatible with the other requirement that you had for not telling some big company whenever you log in somewhere? Do you think at the moment you can't have both of those things? So the question is persona basically acted as a single sign-on solution. You could log into persona once and then are logged into a number of other websites and if I think that approach does not work right now without telling or with that concern of privacy against those big companies, I think with the current protocols, it doesn't work because you're telling them both to protocol and OpenID Connect protocol require you to send a request on every login. So you basically have this centralized knowledge of where you log in anytime. There's a potential that we find a protocol where it's not the case with the current protocols we're not there and so if you don't want that, you probably need to look at something on your own side, unfortunately. The other ID had some ideas or the protocol that persona used had some chance to not tell someone every time you log in but unfortunately it didn't get enough usage. Thank you. We're running out of time for questions. Please give a big round of applause for all that. Thank you.