44 lines
1.5 KiB
Markdown
44 lines
1.5 KiB
Markdown
|
---
|
||
|
|
title: Rationalizing User Data
|
||
|
|
description: "Like how do I approach storing sensitive user data in Bubble?"
|
||
|
|
date: 2025-01-07T21:34:12-08:00
|
||
|
|
draft: false
|
||
|
|
category: article
|
||
|
|
---
|
||
|
|
|
||
|
|
|
||
|
|
This is a stream of concious post where I go through the process of figuring out
|
||
|
|
how I am going to store user data in my [bubble project](https://git.shockrah.xyz/shockrah/bubble)
|
||
|
|
|
||
|
|
Schema for the users can be found here: [link](https://git.shockrah.xyz/shockrah/bubble/src/branch/main/db/setup-tables.sql)
|
||
|
|
|
||
|
|
|
||
|
|
# Pre-requisites
|
||
|
|
|
||
|
|
* Using Postgres
|
||
|
|
* Hashed and salted passwords
|
||
|
|
|
||
|
|
# User ID's
|
||
|
|
|
||
|
|
By default I was going to use regular ID's that increment on each insertion.
|
||
|
|
Considering using some form of UUID's for the sake of a slight increase in sec.
|
||
|
|
Even though this isn't a major form of security, every layer towards
|
||
|
|
better security counts, and I see this as one more layer to add.
|
||
|
|
|
||
|
|
|
||
|
|
UUID's tend to suffer from indexing issues but later versions of UUID seem to
|
||
|
|
have this figured out.
|
||
|
|
|
||
|
|
After some reading v7 seems like the move.
|
||
|
|
|
||
|
|
* Time based meaning sorting ( and thus searching ) is reasonably performant
|
||
|
|
* Sufficient entropy for this case ( 74 bits ). We want ****some* entropy but also
|
||
|
|
don't want to nuke performance
|
||
|
|
* While we want to make it harder to guess, aiming for "unguessable" is just not
|
||
|
|
reasonable. UUIDv4 is best for that but compromises performance so hard it's not
|
||
|
|
worth it in the grand scheme of things
|
||
|
|
|
||
|
|
|
||
|
|
IDK v7 feels like a good middle ground for security + performance for the **user id**
|
||
|
|
|