The roads I take...

As mentioned previously here on my blog, my FOSDEM 2017 talk ended up opening up the code for my own OAuth2 login server which I created following my earlier post on the login systems question.

The video from the talk is now online at the details page of the talk (including downloadable versions if you want them), my slides are available as well.

The gist of it is that I found out that using a standard authentication protocol in my website/CMS systems instead of storing passwords with the websites is a good idea, but I also didn't want to report who is logging into which website at what point to a third party that I don't completely trust privacy-wise (like Facebook or Google). My way to deal with that was to operate my own OAuth2 login server, preferably with open code that I can understand myself.

As the language I know best is PHP (and I can write pretty clean and good quality code in that language), I looked for existing solutions there but couldn't find a finished one that I could just install, adapt branding-wise and operate.
I found a good library for OAuth2 (and by extension OpenID Connect) in oauth2-server-php, but the management of actual login processes and creating the various end points that call the library still had to be added, and so I set out to do just that. For storing passwords, I investigated what solutions would be good and in the end settled for using PHP's builtin password_hash function including its auto-upgrade-on-login functionalities, right now that means using bcrypt (which is decent but not fully ideal), with PHP 7.2, it will move to Argon2 (which is probably the best available option right now). That said, I wrote some code to add an on-disk random value to the passwords so that hacking the database alone will be insufficient for an offline brute-force attack on the hashes. In general, I tried to use a lot of advice from Mozilla's secure coding guidelines for websites, and also made sure my server passes with A+ score on Mozilla Observatory as well as SSL Labs, and put the changes for that in the code as much as possible, or example server configurations in the repository otherwise, so that other installations can profit from this as well.
For sending emails and building up HTML as DOM doucuments, I'm using helper classes from my own php-utility-classes and for some of the database access, esp. schema upgrades, I ended up including doctrine DBAL. Optionally, the code is there to monitor traffic via Piwik.

The code for all this is now available at https://github.com/KaiRo-at/authserver.

It should be relatively easy to install on a Linux system with Apache and MySQL - other web servers and databases should not be hard to add but are untested so far. The main README has some rudimentary documentation, but help is needed to improve on that. Also, all testing is done by trying logins with the two OAuth2 implementations I have done in my own projects, I need help in getting a real test suite set up for the system.
Right now, all the system supports is the OAuth2 "Authorization Code" flow, it would be great to extend it to support OIDC as well, which php-server-php can handle but the support code for it needs to be written.
Branding can easily be adapted for the operator running the service via the skin support (my own branding on my installation builds on that as well), and right now US English and German are supported by the service but more can easily be added if someone contributes them.

And last but not least, it's all under the MPL2 license, which I hope enables people easily to contribute - I hope including yourself!

Yay! My talk about "Web Logins after Persona - How I solved logins on my small websites" has been accepted for the Mozilla DevRoom at FOSDEM 2017!

That talk is a followup on my earlier post on the login systems question, which I ended up solving by writing my own OAuth2 login server based on oauth2-server-php. While that library provides the actual functionality for OAuth2, I had to build a system around it that handles the actual registration and login and the API for retrieving an email address for the logged in user.

I would like to open up the code for that server to the public at FOSDEM!

For that, I need someone (hopefully multiple people) to review the code to be sane security-wise (an in-depth audit is probably not needed yet, but review for sanity for sure), as I have it deployed myself and don't want the open code to be a risk for me, and also I want it to be fine for people to deploy and depend their own (small) websites on this system for login.

It's basically all PHP code, but it's not too much, the PHP files of the project itself are just about 900 lines long altogether, though it uses the document and email classes from my php-utility-classes as well as oauth2-server-php and a bit of doctrine DBAL, though I don't think the latter two need any review for sanity. The JS is minimal and the CSS no issue for security sanity.

I have one Mozillian who has volunteered and should look into the code soon, but I'd like to have two or three people to take a look, if possible.

If you can help, please let me know with a reply on this post (leave your email, as I'll contact you there), Telegram, Diaspora*, or email and tell me why/how you are qualified to review this code.

Thanks and Happy Holidays!

I put a lot of work into my content management system in the last week(s), first because I had the time to work on some ongoing backend rework/improvements (after some design improvements on this blog site and my main site) but then to tackle an issue that has been lingering for a while: the handling of logins for users.

When I first created the system (about 13 years ago), I did put simple user and password input fields into place and yes, I didn't know better (just like many people designing small sites probably did and maybe still do) and made a few mistakes there like storing passwords without enough security precautions or sending them in plaintext to people via email (I know, causes a WTF moment in even myself nowadays but back then I didn't know better).

And I was very happy when the seemingly right solution for this came along: Have really trustworthy people who know how to deal with it store the passwords and delegate the login process to them - ideally in a decentralized way. In other words, I cheered for Mozilla Persona (or the BrowserID protocol) and integrated my code with that system (about 5 years ago), switching most of my small sites in this content management system over to it fully.

Yay, no need to make my system store and handles passwords in a really safe and secure way as it didn't need to store passwords any more at all! Everything is awesome, let's tackle other issues. Or so I thought. But, if you haven't heard of that, Persona is being shut down on November 30, 2016. Bummer.

So what were the alternatives for my small websites?

Well, I could go back to handling passwords myself, with a lot of research into actually secure practices and a lot of coding to get things right, and probably quite a bit of bugfixing afterwards, and ongoing maintenance to keep up with ever-growing security challenges. Not really something I was wanting to go with, also because it may make my server's database more attractive to break into (though there aren't many different people with actual logins).

Another alternative is using delegated login via Facebook, Google, GitHub or others (the big question is who), using the OAuth2 protocol. Now there's two issues there: First, OAuth2 isn't really made for delegated login but for authentication of using some resource (via an API), so it doesn't return a login identifier (e.g. email address) but rather an access token for resources and needs another potentially failure-prone roundtrip to actually get such an identifier - so it's more complicated than e.g. Persona (because using it just for login is basically misusing it). Second, the OAuth2 providers I know of are entities to whom I don't want to tell every login on my content management system, both because their Terms of Service allow them to sell that information to anyone, and second because I don't trust them enough to know about each and every one of those logins.

Firefox Accounts would be an interesting option, given that Mozilla is trustworthy on the side of dealing with password data and wouldn't sell login data or things like that, may support the same BrowserID assertion/verification flow as Persona (which I have implemented already), but it doesn't (yet) support non-Mozilla sites to use it (and given that it's a CMS, I'd have multiple non-Mozilla sites I'd need to use it for). It also seems to support an OAuth2 flow, so may be an option with that as well if it would be open to use at this point - and I need something before Persona goes away, obviously.

Other options, like "passwordless" logins that usually require a roundtrip to your email account or mobile phone on every login sounded too inconvenient for me to use.

That said, I didn't find anything "better" as a Persona replacement than OAuth2, so I took an online course on it, then put a lot of time into implementing it and I have a prototype working with GitHub's implementation (while I don't feel to trust them with all those logins, I felt they are OK enough to use for testing against). That took quite some work as well, but some of the abstraction I did for Persona implementation can be almost or completely reused (in the latter case, I just abstracted things to a level that works for both) - and there's potential in for example getting some more info than an email from the OAuth2 provider and prefill some profile fields on user creation. That said, I'm still wondering about an OAuth2 provider that's trustworthy enough privacy-wise - ideally it would just be a login service, so I don't have to go and require people to register for a whole different web service to use my content management system. Even with the fallback alone and without the federation to IdPs, Mozilla Persona was nicely in that category, and Firefox Accounts would be as well if they were open to use publicly. (Even better would be if the browser itself would act as an identity/login agent and I could just get a verified email from it as some ideas behind BrowserID and Firefox Accounts implied as a vision.)

I was also wondering about potentially hosting my own OAuth2 provider, but then I'd need to devise secure password handling on my server yet again and I originally wanted to avoid that. And I'd need to write all that code - unless I find out how to easily run existing code for an OAuth2 or BrowserID provider on my server.

So, I'm not really happy yet but I have something that can go into production fast if I don't find a better variant before Persona shuts down for good. Do you, dear reader, face similar issues and/or know of good solutions that can help?

I've been hearing about git for a long time as I already was following LWN.net closely when all those BitKeeper vs. Linux kernel problems came up and Linus started to work on a replacement. Meanwhile, over just two years, that technology has matured enough that it's being used by a wide rage of projects nowadays.

While the Mozilla project will use Mercurial ("hg") in the future, I suggested trying git a few times and probably annoyed decision makers a bit with that, but our big problem is that we need decent support on Windows, and git is not there yet (even though current development looks promising for the future). Mercurial is probably a good choice as well, interestingly it has been started about at the same time as git for practically the same reasons - and it's probably compatible in multiple ways: Not only are both distributed version control systems (DVCSes), they're both using SHA-1 hashes to identify revisions, and even screen shots of their graphical tools look similar.

In any case, I've personally never used anything else than CVS, and that aged, centralized, per-file version control system has served me well for my private projects. I understand its usage as well as its repository quite well and I hardly ever run into its real problems like file moving or such.

That said, I always found git's concept of tracking content instead of files interesting (that's why file moves are more or less irrelevant to it), and tracking changesets instead of single-file-changes could also prove useful in my personal projects. Oh, and then there's one thing that really attracts me about DCVS solutions: I'm doing lots of work when I'm on a train without a net connection, history can prove useful to have there, as well as tracking several different changes to a single file - and then I'm merging this to my other computer and two production systems (or actually, checking in to a central repository and check out on those systems, in the CVS model). And then, learning new technologies is always a good thing.

So, I had enough reasons to try out git for my personal projects, and I spent about 6 hours today figuring out how to work with it, a set of directories I wanted to import, and how to import those from CVS. So far, it looks like everything has worked. Oh, and the PHP code generating this website and blog (the CBSM system) is now running off a git checkout.

After some time of working with this, I'll see if I want to git even more code into such repositories - for now, let's see how this works out

Finally I managed to implement pingback in addition to TrackBack, and it was interesting to implement both, to compare them from a developer's perspective - as both are technologies that enable other blogs to link back blog entries that link them and this way create a permanent connection between two blogs.

One target of pingback is said to be that it should be "implementable with minimal effort", I also read in a few places that it should not attract spam as easily as TrackBack. The latter has been achieved quite nicely, as the pingback client needs to tell the server the source URL containing the original link as well as its target, and the server needs to verify this link to this target actually exists in the source. TrackBack on the other hand just sends the the URL to link back to and needs no verifications, so strictly according to the spec, a TrackBack server just links back to anything anyone else tells it to link. Of course, most TrackBack servers nowadays do verify that their blog is linked from the source - as does this blog here, like I pointed out in a recent post here.
The ease of implementation was not such a clear win for pingback though in my case. Where it clearly wins over TrackBack is "autodiscovery" (automatically discovering link targets in a blog entry that are able to link back via one of those technologies): While TrackBack uses a rather complicated to detect RDF snippet that needs to be placed in the entry, pingback uses a very easy to read HTTP header (and an also easy to detect HTML <link> tag as a fallback) to detect if some page is pingback-enabled. Telling the other blog that it should link, i.e. actually "pinging" it, is quite simple on the TrackBack side though: do a simple HTTP POST with urlencoded data, get very simple XML as a reply that tells if it was successful or not, and that's it. Pingback on the other hand achieves that part via an XML-RPC call. This might be easy to implement if you have an XML-RPC server running on your site already, but if you don't, it requires you to send a rather deeply structured XML document in a POST request as a client, and as a server, to retrieve the data from that doc (I needed to spend some time to even find out how to get this body of the incoming request in PHP) and send an even more complicated XML reply. So the implementation of the actual ping is (without having working XML-RPC support in place already) much harder for pingback than for TrackBack. I guess there's rarely a technology that has only good sides to it...

BTW, I know that there's some XML-RPC support bundled with PHP (via XMLRPC-EPI), but as there's no good documentation of it anywhere (one case where the else good PHP manual really sucks), I even felt safer to manually deal with that form of communication.

That said, I got both technologies to hopefully work now on this blogging system, including autodiscovery for both of them (if both are supported, pingback is preferred), and I hope users of CBSM and our community system will like them.

OK, after some more work, this blog is available through RSS and Atom feeds (Firefox and IE7 users should see the feed icon popping up, SeaMonkey users with the link toolbar enabled should see them listed there under "More > Other Versions" (from the blog overview page).

Once I have the tagging system in place, there will be filtered feeds available that list only certain tags and/or languages. For now, the feeds just list the articles the blog overview page carries - the RSS feed has subjects and links, the atom feed includes the full articles as well.

I probably should try to get the blog syndicated on some planet sites now