
The New Firebase Security API - mayop100
http://blog.firebase.com/post/38234264120/the-new-firebase-security-api
======
ibdknox
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.

------
silverlight
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>

------
toddmorey
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>

------
blake8086
It's nice to see "Uses BCrypt for password storage" instead of hand-wavy
"industry standard" or "strong encryption" or something like that.

~~~
Pewpewarrows
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.

~~~
mayop100
[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.

------
mej10
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.

~~~
tptacek
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.

~~~
danielweber
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?

~~~
patio11
_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.)

~~~
arohner
> 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.)

Can you please elaborate more, or link to articles about why this is a bad
idea? What are the common failure scenarios that splitting normal & admin
users fixes?

~~~
patio11
Briefly: there are a lot of common vulnerability classes which can compromise
a user of your application / their cookie / their DB record, for example mass
assignment (to update the "role" attribute in a free trial account to "admin")
or XSS (tweet at your support account and have them click a link to your
domain, bam, the adversary now has your cookie and can log in as you).

Separating the admin app and the normal app upper-bounds the impact of those
flaws at something lower than "The worst thing someone could possibly do with
the admin console." Given that many admin consoles have fairly extensive
functionality, that's generally a good idea. (I mean, my businesses are pretty
low risk as things go, and my admin consoles would trivially do about $20k of
damage just with refunds if compromised.)

------
incomethax
From any one of the many security experts that hang out here - can you give us
an assessment of how secure this actually is?

~~~
krenoten
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?

~~~
mikelehen
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!)

------
JPKab
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!

------
nbashaw
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

------
tadruj
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.

------
buu700
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>

~~~
mikelehen
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). :-)

~~~
buu700
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.

------
cjg
The example given doesn't address CRSF. Does anyone know if the API can
prevent them?

~~~
mikelehen
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.

------
jnwng
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!

~~~
mayop100
[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.

------
bonaldi
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?

~~~
mikelehen
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.

~~~
bonaldi
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.

------
tehskylark
Great work, the documentation as well as the tutorial are very easy to read
and understand.

------
yeldarb
Been playing with the beta for the last few weeks and love it. Props to the
Firebase guys.

------
Gilly_LDN
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.

------
aioprisan
how is this different than meteor's security model?

~~~
debergalis
[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.

~~~
mayop100
[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).

~~~
mayop100
I should also mention that Firebase does let you run trusted code if you want
to -- you can run a server as a Firebase client using our Node.js library or
using our REST API. Then you can do anything you would normally do with a
server, and still get Firebase's real-time updates.

The model is reversed in this case though, where instead of clients talking to
your application server, clients talk to your database (Firebase), and your
application server only ever talk to your database (Firebase). It's a bit of a
conceptual shift, but we have many customers doing this in production and it
works quite well.

------
eze
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.

~~~
mikelehen
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.)

~~~
eze
Thanks! I'll be eagerly waiting for my access code ;-)

------
fudged71
I signed up just last night! Great to see such an intuitive product. Can't
wait to start building with it :)

------
d0m
So, the idea of using json rules rather than a simple javascript function is
for speed performance?

~~~
mikelehen
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.

~~~
batgaijin
What are you using for static analysis? What are your thoughts on Fay?

~~~
mikelehen
Fay looks neat! I'll have to play with it.

Since the whole rules language is custom, we're not using any off-the-shelf
projects presently, and to be honest, we've only scratched the surface of
what's possible.

Most of what we have in place right now is at the level of type-checking and
other expression-correctness checks (we're intentionally more strict about a
number of things than JavaScript).

But given the nature of the rules we can do a lot of cooler analysis, like
detect redundant or conflicting rules. We should also be able to do
interesting analysis for the developer like answer questions like "What parts
of my Firebase data can an unauthenticated client read or write?", "What parts
can a user authenticated as 'joe' read or write?"

This sort of analysis should help developers reason about their rules and
verify their correctness. Honestly, I'm pretty excited about the
possibilities. :-)

------
rparet
How does this compare to security offerings from other BaaS providers like
Kinvey, Parse, etc?

~~~
mayop100
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.

