Best practice for avoiding sequential integers as database IDs

[Ali]

Hi,

The IDs in my databases are currently simple sequential integers. This, of course, makes the databases prone to brute-force attacks.

I wonder what would be a good practice to avoid that?

One solution I ran into is incorporating a UUID (created using the uuid library) into all databases. Is this the right way?

Any suggestions or tips would be greatly appreciated!

Thank you,

Ali

[Dave S]

What sort of brute-forcing are you imagining?  Why would accessing the first entry, for example,  in the database be a problem ?  If that entry represents something with special privileges, perhaps that table shouldn't be directly accessed by users  ... for instance, the users table.  Or are you expecting an attempt to turn knowing that Company X is n the  vendor database, poking around to see if Company Y is also there?

/dps

[Ali]

Let's take the example of a company that must maintain the confidentiality of its total customer count. If the URLs of user pages directly mirror the ID of the corresponding user in the database, they inadvertently divulge information about the size of the customer base.

Based on my research, it appears that UUIDs (Universally Unique Identifiers) are an advisable way to circumvent the use of sequential integers as database IDs. One important consideration, however, is that in such a scenario, we should add an index to the UUID column to enhance the speed of retrieving records from the database. 

If anyone has any further insights, please feel free to share.

[Luca de Alfaro]

I have used a UUID exactly for the purposes you indicate. 

I wonder if you could also use a reversible hash function to map the id to a hashed id that you could make visible to the public. 

That would avoid the use of a second index.  If you came up with an implementation in Python I would be happy to see it. 

Luca

--
You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/52b0b4be-3bbd-457d-8fc9-2bf40fc097een%40googlegroups.com.

[Ali]

Using a reversible hash function speeds up record retrieval, although at the cost of reduced security. That is because the decoding process is typically performed using a secret key. If that key is compromised for any reason, then all the proxy IDs will suddenly become decodable.

That being said, sometimes the speed requirements of a website may totally justify the approach above. To implement this approach, the following two resources might be helpful:

- (Formal cryptography): Trapdoor functions

- This StackOverflow post

Just some thoughts that crossed my mind!

[Ali]

Speaking of UUIDs, I have a question about this part of the documentation. I wonder why a length of 64 is used for the UUID field. Is the length of a UUID4 code not always 36 characters?

db.define_table('person',
                Field('uuid', length=64),
                Field('modified_on', 'datetime', default=now, update=now),
                Field('name'))

db.person.uuid.default = db.thing.uuid.default = lambda:str(uuid.uuid4())

Thank you!

[Ali]

Also, here is another related point.

If one does not like UUIDs because of their length, the nanoid library (Javascript and Python) provides shorter codes (21 characters instead of 36) with the same entropy. 

[Luca de Alfaro]

Yes a reversible hash function would not give true security guarantees, just a bit of obfuscation so you don't see that you are customer/14 for instance. 

Luca

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/90cd6ebe-6746-4653-8f1f-d0ad66d6856bn%40googlegroups.com.