back
51 comments
This is the one big thing that really needed to happen to Firebase to get it ready for the world and having worked with these guys a bit, I know it was a difficult problem to solve. I think the solution they came up with is actually pretty novel and exhibits the qualities I strive for these days:

1) It's as declarative of an approach as it can be without sacrificing flexibility.

2) It follows the structure of your data and is itself a datastructure that can be trivially manipulated.

3) It centralizes a concern. Security measures often end up spread all over the place, making it very difficult to reason about what is or is not correctly handled. Not so with this model.

I'm excited to see what people do with Firebase now that the one thing that was really holding it back has a solution. I know from my standpoint, it's certainly nice to have someone else dealing with the nightmares of real-time scaling and security so that I don't have to.

We've been using Firebase now for about 6 months to power Roll20[1], it's allowed us to grow from 100 to 1,000 concurrents without having to make any changes to our code or even think about handling the additional scale. That's incredibly valuable to us, since it frees us up to focus on creating features and helping customers, not worry about keeping yet another server from crashing. Andrew, Michael, and James have always been available to answer questions, and it's been a pleasure to watch Firebase grow. The new security API is just the icing on the cake for us since it will allow us to further fine-tune what different participants have the ability to do in our games.

I highly recommend it if you're looking at creating a real-time app!

[1] http://roll20.net

This is really great work, guys. We've been using Firebase for a while now. The uptime, low-latency, and consistency have been impressive. A good security framework was really our last hurdle. We're digging in to the new security features and pretty happy so far. Another good resource (in addition to the blogpost above) is the quick start page. [1]

Also, one side note: it's not always clear from reading the docs, but changes to the security rules can be made dynamically and take immediate effect.

[1] https://www.firebase.com/docs/security-quickstart.html

It's nice to see "Uses BCrypt for password storage" instead of hand-wavy "industry standard" or "strong encryption" or something like that.
Hand-wavy terms are preferred if the text is end-user facing (and when end-users tend to not be too technical). Of course, a tooltip or "more details" link explaining the real technologies should then be used.
[Firebase founder here] This is one of the nice things about running a company that is 100% developer focused. We can communicate in clear terms with customers that actually understand the nuances of what we're building. We'd much rather be specific than hand-waving.
Has this been pentested or audited by a security firm?

I think this is awesome and I am glad you have it working. I'll be seriously considering Firebase for future projects.

For what it's worth, and as weird as this is going to sound:

You don't in particular want the "security API" of an app framework to get externally validated. For the most part, the "security" components of app frameworks are boring, modulo some really simple- to- answer questions ("how do you store passwords", "how do you handle password resets").

When people talk about "security frameworks", they tend to be thinking about what we used to call "AAA systems" (authentication/"authn", authorization/"authz", and accountability/logging). You don't need to be an appsec practitioner to look at an AAA system and see whether it's any good. Does it apply authn by default? How easy would it be to accidentally expose a method that didn't require a login? Does it apply authz rules by default? How much of a pain would it be to reliably apply authz rules across my project? If stuff is easy and has sane defaults, you'll use them and benefit --- like you do in Rails, if you use association finders off a "current user" instead of the class object finders.

The bad news is, what you want tested in an app framework is everything else. How's it handling database persistence? How does it handle corner cases, like deliberately pathologically huge queries, out-of-range numerics, conversions between multipart and standard encoding, output encoding of HTML, Javascript, and CSS, CSRF validation, file upload, database column access, &c &c. It's the stuff you don't normally think of as "security code" that's most likely to bite you.

At Matasano, we have a "seven deadly features" in web apps that we tend to find the first and worst flaws in web apps in; they're:

1. Password reset

2. Email functionality

3. Interfaces to thick clients; "REST API" &c

4. File upload

5. File download

6. Templating

7. "Advanced search"

Only one of those is a security feature, and it's also a security feature that most "security APIs" don't actually implement (because every app wants to have a different UX for it).

Lest this sound self-interested: most frameworks haven't been formally externally tested. I'd be thrilled if someone had their framework tested formally, but I don't tell people not to use Rails or Django or Spring just because they haven't been pentested by an appsec firm.

How should one properly secure a "password reset" feature?

and/or

What are the most common dumb things people do with a password reset feature?

How should one properly secure a "password reset" feature?

Ooh, I think I can actually do this: You send the address on file an email which contains a random, time-limited, one-use token which allows them to log into their account. You should not disclose presence or absence of the account via the reset mechanism on the site (only via email), but that's a comparatively minor issues. A successful password reset should end all in-progress sessions for the account. You should also do all the table-stakes web development things like e.g. not allowing SQL injection or XSS on the page.

There's plenty of failure conditions for password resets:

1) You create non-random reset tokens, such as MD5(user.id) or MD5(user.email), potentially compromising security of accounts.

2) You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)

3) You allow password reset tokens to get re-used, which increases the attack surface against individual accounts by e.g. making saved-to-disk emails into attack vectors for them. (Standard reset mechanisms only make emails-in-flight into attack vectors.)

During the design process, we solicited feedback from several security experts (security firms and ad-hoc hackers alike). It hasn't gone through a formal outside audit at this point though. (And please do keep in mind that we're still a beta product. We're pretty confident in what we've built, but we're not making promises at this point.)
From any one of the many security experts that hang out here - can you give us an assessment of how secure this actually is?
I'm curious about this as well. When I hear "without writing any server code" in the demo video, my mind says that this is client-side validation, which does not suggest it is secure to me. What server-side validation happens under the hood to deal with modified clients/proxies like Burp?
Here's a little secret. The security rules you, as a Firebase developer, write for your Firebase, are actually server-side validation code. It just doesn't look like typical code, and we've carefully designed them to have a lot of good properties regarding performance, correctness, and analyzability. And we (Firebase) take care of enforcing them for you.

But it /is/ server-side validation, that you as a developer get to specify.

(That said, we're definitely happy to get feedback on our approach from any security experts out there that want to take a look!)

I have a beta acccount and was waiting for this until I started playing around with it. Thanks! I'm pretty excited about building something on top of this platform.

The Scratchpad.io tool that has been on HN for the last couple of days has really blown me away with what Firebase is capable of. Keep up the good work guys!

We used firebase to power Scratchpad.io's back end (launched yesterday) and it was an awesome experience! The security features were super easy to use
I especially like Firebase tutorials and docs. After finishing tutorial on Firebase first launch I immediately knew where and how can I use Firebase in the future. When the time came we used it for real-time worker/web-app communication at http://dubjoy.com/ and it worked like a charm. I still don't know how to use web sockets and I hope I never will :) While working with Firebase we needed some ACL-like security features and Firebase delivered again. Amazing.
Congrats guys! This is seriously impressive; I'm really excited to finally be able to put out some production code with Firebase.

As an aside, the model you guys ended up with is fairly similar to the one I proposed back in April: http://news.ycombinator.com/item?id=3864430

Thanks! We're certainly grateful for all of the input and feedback we received while designing this thing (especially from our beta users who came through time and time again, giving us countless security use cases and providing feedback on our prototype implementations).

I will point out though that what you described looks like an ACL system with groups (akin to unix permissions), and we think our Security Rules system is actually quite a bit more powerful than that (you could easily build ACL / groups on top of it, but you can build lots of other models too). :-)

Ah, brilliant. I haven't had time to dig too much into it yet, but it'll be really interesting to see how powerful this thing is.
The example given doesn't address CRSF. Does anyone know if the API can prevent them?
Firebase doesn't use cookies for authentication so CSRF isn't an issue. You have to explicitly call auth() on our JavaScript SDK with valid credentials, or include valid credentials in the querystring of a REST request.
I like having the flexibility of being able to use Firebase's servers or my own, makes it easy to use for completely client-side apps, or alternatively you can throw it on top of a server-side application. Great work guys!
[Firebase founder here] We did a ton of interviews with devs, and we found that authentication was one of the areas where developers wanted the most control / customization. We therefore opted for maximum flexibility here.
Very interesting. How are rules updated dynamically? Take a Flickr picture for example. I start it as public, then later decide I want to make it friends & family. How does the client side securely update those rules?
This is where Security Rules shine over ACL's or other more rigid security models. As the application developer, you have complete control over that sort of functionality since the rules are quite flexible and have direct access to your Firebase data.

So you could store a 'public' flag on every picture in your Firebase data, and then write a single rule that checks the value of that flag, and if it's true, allows anonymous access (and if it's not true, checks that the accessing user is in the picture owner's friends/family list).

Assuming your rules let the picture owner edit the 'public' flag, they'll be able to flip it on and off, granting or revoking access to non-friends/family. And since everything in Firebase is real-time, the change will instantly take effect.

Thanks, that makes sense. The rules are unchanged, but they refer to db fields, that themselves are protected by the rules.

I was critical of the firebase security situation when they launched, but this looks like a good solution indeed.

Great work, the documentation as well as the tutorial are very easy to read and understand.
Been playing with the beta for the last few weeks and love it. Props to the Firebase guys.
This is a great update and really opens it up for a hackathon project that I wanted to extend after the event, but the security issues had meant that it was better to wait until now.

Well done James T. and the rest of the Firebase team.

how is this different than meteor's security model?
[meteor dev] Meteor treats the server as an environment for running arbitrary privileged code. You can write server-side logic that consults third-party services, logs client writes to a separate audit trail, keeps authentication state between requests, or implements complex transactions across multiple tables. Similarly you can write code to run periodic database updates on an interval, or respond to incoming HTTP requests from other clients.

Not all apps need this stuff right away, of course, and some never do. But it's hard to do these things w/o a secure server environment for privileged code.

And then of course there's the usual tradeoffs between having control over your hosting environment (a la Meteor) and outsourced backends as a service (a la Firebase).

We're big fans of Firebase, BTW. We think more databases will move to a realtime model. Excited to check this out.

[Firebase dev] I've mentioned this in the chat several times, but I should probably mention this on the HN thread as well.

We're big fans of Meteor as well. Firebase is just a data layer -- we do high-performance, scalable real-time data sync -- but we aren't a complete Framework for building an app. Generally devs will want to use something like Meteor (or Ember, or Backbone, or Spine, etc) to help them organize their code and manipulate the DOM.

In the future we hope to have a Meteor integration, so you can power your Meteor app without running any of your own servers (and do it on a super-low-latency, highly scalable backend).

Meteor relies on developers writing server-side code. This is flexible, but it means you need to run your own servers -- meaning scaling, operations, etc are up to you. Scaling real-time / persistent connections is especially challenging.

Our rules are expression-based, so they have fast and predictable execution times, meaning we can run these on our own servers and scale your app for you with guaranteed performance.

Our rules also let you specify all of your security logic in one place, rather than sprinkling it around your code, meaning it's easier to review and reason about (and avoid holes).

Does anybody know how much the Candle Plan is likely to cost once Firebase leaves beta? Assuming that plan will remain in place, that is.
The Candle Plan is and will continue to be free! (All of the pricing on the website is just to give people an idea of what the pricing will be when we leave beta. It's not being enforced right now.)
Thanks! I'll be eagerly waiting for my access code ;-)
I signed up just last night! Great to see such an intuitive product. Can't wait to start building with it :)
So, the idea of using json rules rather than a simple javascript function is for speed performance?
Michael from Firebase here. By using declarative rules instead of arbitrary code to enforce Security, we can do lots of optimization and guarantee predictable execution time (arbitrary code can take an arbitrarily long time to execute). It also lets us do various static analysis on your rules to catch common mistakes.

Having rule expressions attached directly to data locations also ends up being much more concise (which means less boilerplate code and less opportunities for mistakes), which we think is important for a security API.

What are you using for static analysis? What are your thoughts on Fay?
It did seem a bit odd/counter to best-practices that the validation code would be wrapped in a string.
Yeah. That bugs us too. :-) We might support a non-JSON format for easier authoring at some point, but we thought JSON was the right starting point since people are familiar with it and it has a lot of good tooling and interoperability advantages.
How does this compare to security offerings from other BaaS providers like Kinvey, Parse, etc?
The key difference is that we are a real-time backend. We push data changes down to clients when things change and trigger callbacks so the apps can remain responsive. Parse, Kinvey, etc are based on a request / response model. I know some of them can do mobile push notifications, but those aren't really analogous and are a separate service from their data service.

We're real-time, all the time.

We're also focused on the data layer of your app, and on the web, rather than being a mobile-focused company.