#uuidv4 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #uuidv4, aggregated by home.social.
-
[Перевод] Опасности первичных ключей UUID в SQLite и оптимизация данных
В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами. Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.
-
UUIDv7 takes the best of two worlds for distributed systems: auto-incrementing ID and UUIDv4. It keeps page splits and fragmentation out of primary key index, while also maintaining cryptographically secure randomness to prevent insecure direct object reference. (This obsoletes UUIDv4, which only tends to bloat every index and cost more with each write operation.)
https://www.youtube.com/watch?v=JbdvmQ_HgJo
#UUID #UUIDv7 #UUID7 #UUIDv4 #UUID4 #AutoIncrement #ID #database #databases
-
UUIDv7 takes the best of two worlds for distributed systems: auto-incrementing ID and UUIDv4. It keeps page splits and fragmentation out of primary key index, while also maintaining cryptographically secure randomness to prevent insecure direct object reference. (This obsoletes UUIDv4, which only tends to bloat every index and cost more with each write operation.)
https://www.youtube.com/watch?v=JbdvmQ_HgJo
#UUID #UUIDv7 #UUID7 #UUIDv4 #UUID4 #AutoIncrement #ID #database #databases
-
[Перевод] Более глубокий взгляд на старый UUIDv4 и новый UUIDv7 в PostgreSQL 18
UUIDv4 как первичный ключ в PostgreSQL обычно ругают за «случайность» — но за этим словом прячется конкретная физика: сплиты страниц B-дерева, рыхлый листовой уровень, фрагментация и лишний случайный I/O при чтении. В PostgreSQL 18 появился UUIDv7 — и это хороший повод посмотреть на проблему не на уровне вкусов, а на уровне того, как реально устроены индекс и heap: от корреляции и ctid до статистики страниц и плотности листьев.
https://habr.com/ru/companies/otus/articles/979212/
#UUIDv4 #postgresql #UUIDv7 #PostgreSQL_18 #первичный_ключ #Btree_индекс #фрагментация_индекса #локальность_данных
-
ULID, UUIDv4 и UUIDv7 в логах nginx: как сделать поиск по ID быстрым и удобным в ClickHouse
Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь возможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ. В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef ). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id; , а также сохранить в access-логах. Однако стандартный $request_id — это просто случайная строка без временной привязки и без структуры, удобной для аналитики. В этой статье мы рассмотрим, как улучшить ситуацию с помощью ULID и UUIDv7.
-
@carlton @kjaymiller @simon something like UUIDv47 can solve the UUIDv7 security related problem 💡
-
UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp)
-
UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp)
-
I recently ran into an interesting discrepancy:
What you see below are 120-bit Session IDs, one printed as hex and one in the format of a #UUIDv4.
After validating their randomness, I would classify the first as secure but raise concerns about the second.
Why?
Well, according to RFC 4122:
"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example."
And that's exactly what a session ID is: an identifier whose possession grants access. As such, UUIDs should not be used in such a case.
What do you think? Is this nitpicking? Or a valid security nuance?
Does the format in which data is displayed have an impact on its security?
I'd love to hear your thoughts.
#Pentesting #AppSec #InfoSec #CyberSecurity #BugBounty #Hacking
-
I recently ran into an interesting discrepancy:
What you see below are 120-bit Session IDs, one printed as hex and one in the format of a #UUIDv4.
After validating their randomness, I would classify the first as secure but raise concerns about the second.
Why?
Well, according to RFC 4122:
"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example."
And that's exactly what a session ID is: an identifier whose possession grants access. As such, UUIDs should not be used in such a case.
What do you think? Is this nitpicking? Or a valid security nuance?
Does the format in which data is displayed have an impact on its security?
I'd love to hear your thoughts.
#Pentesting #AppSec #InfoSec #CyberSecurity #BugBounty #Hacking
-
Идентификаторы в БД: INT vs UUID
Привет! Меня зовут Женя, я бэкенд-разработчик, и в этом посте хотела бы кратко обсудить плюсы и минусы разных вариантов идентификаторов в базе данных.
-
#Proxmox just generates a #UUIDv4 like
3b7d2d2c-3732-41db-a678-8bc4aeaf9155 as a secret for auth tokens? 😱
This looks a lot like a bad security practice to me, especially when RFC4122 says:"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation."
-
#Proxmox just generates a #UUIDv4 like
3b7d2d2c-3732-41db-a678-8bc4aeaf9155 as a secret for auth tokens? 😱
This looks a lot like a bad security practice to me, especially when RFC4122 says:"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation."
