I am a software developer based near Melbourne, Australia. Most of my days are spent coding in Python and JavaScript, commercially as an engineer at Mozilla as well as for a variety of open-source projects. I also maintain a strong interest in logic programming, mainly as a result of my doctoral thesis. Read more about me and check out my curriculum vitae if you want to know more.
Exploring Security on persona.org
A few weeks ago, I was involved in discovering a security flaw in the pre-beta version of login.persona.org, the hosted account manager that drives Mozilla Persona. It was fixed quickly, but was not publicly disclosed until the team could conduct a full review of any potential impact. It is public now, and we're confident that no users were affected, so I wanted to share my take on the experience.
The underlying bug I discovered was Bug 793579, and on the surface it was quite unremarkable – an input validation routine that didn't cover all the edge cases, the kind of bug that every working programmer has committed to code at least once1. But I found the process of discovering, exploring, and finally escalating the bug into a security breach to be a remarkable learning experience.
I've always believed that you learn more about yourself from your failures than you do from your successes, and the same seems to be true about software. I learned more about the security measures underlying persona.org, and about the philosophy of software security in general, through one afternoon of trying to make it fail than through a year of theorising about how it should succeed.
This post is a bit of a ramble, but I hope it will prove interesting to other developers. I want to talk about:
- The original bug that I discovered, and how it could easily have been an immediate full system exploit.
- The multiple layers of additional security that kept me from exploiting the bug straight away.
- The missing layer of security that ultimately let me turn the bug into a working exploit.
- Some resultant amateur philosophising on software security in general.
The final outcome of my little adventure might seem counter-intuitive: the process of penetrating the defences on persona.org has actually increased my confidence in the ultimate security of the system. The fact is, bugs do happen, especially while a system is under heavy development. But its focus on multiple layers of security gives persona.org a strong set of defences to limit any potential fallout.
Oh, and to prevent any confusion: I am employed by Mozilla, but am not part of the team behind Mozilla Persona. As far as this story is concerned, I am simply an interested third-party.
Securing Pyramid with Persona and MACAuth
Mozilla Persona went into beta release last week, and it has been very exciting to see the interest and positive press it has generated. I particularly liked the release of pyramid_persona and the accompanying article Quick authentication on pyramid with persona – it is cleaner, simpler, and more feature-full than my attempt at Pyramid/BrowserID integration from last year. Great stuff!
But there is one weak point to using Persona for authentication: it makes automated access difficult. The login flow depends heavily on javascript and assumes that authentication will involve a real live user and a full-blown web-browser. Scripting access to your site via something like requests would be tricky at best, and downright impossible in the general case.
Most of the webapps we build at Mozilla Services are meant for machines, not people, so we've had to tackle this problem head-on. We have found that a combined authentication approach works very nicely – we provide Persona for live users, and the much more automation-friendly MAC Access Authentication for machines.
In this post I'll show you how easy it can be to combine the two, using pyramid_persona and pyramid_macauth for the heavy lifting, and pyramid_multiauth to tie them both together.
