0

I'd like to use Firebase to make publicly-readable data whose location is difficult to guess. So, to give someone access to the data stored in "element [element ID = X]", I'd like to just send them "X", instead of sending them "X" along with a security token crafted to give them access to the element. Firebase's push() and childByAutoID seem like a natural fit: I can grant public read access to all individual elements, but deny public listing. My code will be blissfully free of token and random number generation. The automatically generated ID is supposed to be unique, and thus should be difficult to guess.

From looking at Firebase.js, it appears the first 8 characters of the automatically generated ID are based on the current timestamp, and the next 12 characters are randomly generated using Math.random(). I assume that the iOS framework does the same thing, and although I can't see the code, the library links to both SecRandomCopyBytes and arc4random.

For my purposes, this looks good enough, but has anyone seen guidance from Firebase on whether we can count on this behavior? I would hate to build code that assumes these names are relatively strong random strings and then have that assumption violated when I upgraded to a newer version of Firebase.

Chris Loer
  • 190
  • 1
  • 12

1 Answers1

5

The purpose of the auto-generated IDs provided by Firebase is to allow the developer to create a chronologically ordered list in a distributed manner. It relies on Math.random and the timestamp to generate an ID unique to that client.

However, if you're going to use the auto IDs as security keys, it may not be the best idea depending on how secure you want your system to be. Math.random is not a cryptographically secure random number generator and since push() relies on it, the IDs generated by it aren't either.

The general concept of giving a user access to some data in Firebase if they know the key is a good one though. We have an example of using this type of security rule, but instead of using push IDs, we use a SHA-256 hash of the content itself (in this particular case, they are images). Hashing the content to generate the keys is more secure than relying on push() IDs.

Community
  • 1
  • 1
Anant
  • 7,408
  • 1
  • 30
  • 30
  • 1
    Is the spec of a push() ID spelled out anywhere? From looking at a few, it seems that it's always 20 characters long, begins with "-", and the remaining 19 characters can can be [A-Z][a-z][0-9] and "-". Anything else? – neverfox Apr 07 '14 at 08:00
  • great question, neverfox. I'd love to know the answer. e.g., can I always count on the dash prefix? – chris Oct 15 '14 at 16:14
  • There are no guarantees about the format of a push ID other than it being a valid Firebase key and the fact that subsequent calls to push() will order the IDs by time. Ideally the app would already know at which paths push IDs are used -- it's not recommended to mix push IDs with custom key names at the same path. – Anant Oct 16 '14 at 18:26
  • 1
    If you are interested to hear about how these IDs are generated, this blog post might be useful: https://www.firebase.com/blog/2015-02-11-firebase-unique-identifiers.html – Anant Apr 15 '15 at 20:07