Shouldn't counter on ObjectID start out random?

[lu...@webconnex.com]

The ObjectID definition says:

"a 3-byte counter, starting with a random value"

http://docs.mongodb.org/manual/reference/object-id/

But in the bson package starts with 0 and increments from there:

var objectIdCounter uint32 = 0

...

i := atomic.AddUint32(&objectIdCounter, 1)

Shouldn't counter on ObjectID start out random?

-

Luke

[Gustavo Niemeyer]

Hey Luke,

Yeah, indeed there's a difference there. Is this affecting your use
anyhow, out of curiosity?


gustavo @ http://niemeyer.net

[lu...@webconnex.com]

We just started using mgo, so I can't say we have yet. It was more of a security concern with the counter starting with a known value.

[Jeff Mitchell]

lu...@webconnex.com wrote:
> We just started using mgo, so I can't say we have yet. It was more of a
> security concern with the counter starting with a known value.

The OID is meant to guarantee uniqueness; it should not be used in any
security context. Especially given that it's only 3 bytes, if you're
exposing it somehow to users or external applications, attempting to
guess a value 16 million times takes essentially no time on modern machines.

--Jeff

[Gustavo Niemeyer]

On Fri, May 24, 2013 at 12:47 PM, Jeff Mitchell
<jeffrey....@gmail.com> wrote:
> The OID is meant to guarantee uniqueness; it should not be used in any
> security context. Especially given that it's only 3 bytes, if you're
> exposing it somehow to users or external applications, attempting to guess a
> value 16 million times takes essentially no time on modern machines.

Not to mention it's monotonically increasing. If you grab the current
value you know the next one.


gustavo @ http://niemeyer.net

[lu...@webconnex.com]

It would still be trivial to brute force, yes.. Having it start with 0 every time you restart the server isn't exactly desired either though, especially if you restart multiple servers you end up with the counters being closer together than they would be if they started out with a random value.

[Jeff Mitchell]

lu...@webconnex.com wrote:
> It would still be trivial to brute force, yes.. Having it start with 0
> every time you restart the server isn't exactly desired either though,
> especially if you restart multiple servers you end up with the counters
> being closer together than they would be if they started out with a
> random value.

But that doesn't matter, so long as they do not end up the same...after
all, it's a value that is supposed to be guaranteed unique, and should
never have any security application.

Brute-forcing shouldn't matter. You shouldn't be using OIDs in such a
way that brute-force guessing of the OID will lead to a security problem
for you.

--Jeff

[Gustavo Niemeyer]

On Mon, Jun 17, 2013 at 6:06 PM, <lu...@webconnex.com> wrote:
> It would still be trivial to brute force, yes.. Having it start with 0 every
> time you restart the server isn't exactly desired either though, especially
> if you restart multiple servers you end up with the counters being closer
> together than they would be if they started out with a random value.

What's the issue with having the values close together? There are
other fields in the id.

That said, it's not the first time this issue comes up. We may as well
just end up changing it so it's expected.


gustavo @ http://niemeyer.net