1.5 KiB
1.5 KiB
| title | description | date | draft | category |
|---|---|---|---|---|
| Rationalizing User Data | Like how do I approach storing sensitive user data in Bubble? | 2025-01-07T21:34:12-08:00 | false | 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
Schema for the users can be found here: link
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