github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-06-03 04:46:19 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #3671] [Security] ID generation should generate UUIDs, not just some random strings #9681

New Issue
Closed
opened 2026-04-13 05:18:21 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-13 05:18:21 -05:00
Owner
Copy Link

Originally created by @KazimirPodolski on GitHub (Jul 28, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3671

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Use e.g. sign-up with email.

Current vs. Expected behavior

Generated record has an ID like v6c7zOwP9oBMDg3QpRdVJPhphrkOVrgu instead of a proper UUID. No proof of cryptographic and collision hardness of better-auth's own generator is to be found.

What version of Better Auth are you using?

1.3.4

Provide environment information

Doesn't matter.

Which area(s) are affected? (Select all that apply)

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

This states:

Battle-tested auth flows and security practices

Except rolling your own random generator is literally one of the oldest mistakes in the book.

Please use Node's randomUUID or something.

Guys @Bekacru @Kinfe123 @ping-maxwell, this is more serious than you think. Apart from purely technical mistake, it also breaks trust in the platform, as other security-related malpractices could be expected randomly.

Originally created by @KazimirPodolski on GitHub (Jul 28, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3671 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Use e.g. sign-up with email. ### Current vs. Expected behavior Generated record has an ID like `v6c7zOwP9oBMDg3QpRdVJPhphrkOVrgu` instead of a proper UUID. No proof of cryptographic and collision hardness of [better-auth's own generator](https://github.com/better-auth/utils/blob/67e06576b8504331fcc9cf51479719ce4fc6db24/src/random.ts#L20-L69) is to be found. ### What version of Better Auth are you using? 1.3.4 ### Provide environment information Doesn't matter. ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context [This](https://www.better-auth.com/docs/comparison) states: > Battle-tested auth flows and security practices Except rolling your own random generator is literally one of the oldest mistakes in the book. Please use Node's `randomUUID` or something. **Guys @Bekacru @Kinfe123 @ping-maxwell, this is more serious than you think.** Apart from purely technical mistake, it also breaks trust in the platform, as other security-related malpractices could be expected randomly.
GiteaMirror added the locked label 2026-04-13 05:18:21 -05:00
GiteaMirror commented 2026-04-13 05:18:24 -05:00
Author
Owner
Copy Link

@KazimirPodolski commented on GitHub (Jul 28, 2025):

I understand there is the ability to override ID generation, but default behavior should not be wrong anyway.

<!-- gh-comment-id:3126403048 --> @KazimirPodolski commented on GitHub (Jul 28, 2025): I understand there is the ability to override ID generation, but default behavior should not be wrong anyway.
GiteaMirror commented 2026-04-13 05:18:24 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Jul 28, 2025):

Thanks for the feedback

First off, we're not "rolling our own crypto", we use getRandomValues under the hood, which is cryptographically secure and available in both browser and Node environments and used by randomUUID itself.

Second, I think the term you're looking for is collision probability, not collision hardness (typically refers to hash functions). In this case, it's more about the probability of generating the same random value twice and depending on how you configure our generator, it can actually offer higher entropy than UUIDv4 for the same length.

You're right that UUID is a well-established standard and it's a good suggestion. But we intentionally chose a more agnostic approach. Users can use UUID, CUID, NanoID or just their db generated ID if they see fit, we don’t want force a specific format.

<!-- gh-comment-id:3129931935 --> @Bekacru commented on GitHub (Jul 28, 2025): Thanks for the feedback First off, we're not "rolling our own crypto", we use `getRandomValues` under the hood, which is cryptographically secure and available in both browser and Node environments and used by randomUUID itself. Second, I think the term you're looking for is collision probability, not collision hardness (typically refers to hash functions). In this case, it's more about the probability of generating the same random value twice and depending on how you configure our generator, it can actually offer higher entropy than UUIDv4 for the same length. You're right that UUID is a well-established standard and it's a good suggestion. But we intentionally chose a more agnostic approach. Users can use UUID, CUID, NanoID or just their db generated ID if they see fit, we don’t want force a specific format.
GiteaMirror commented 2026-04-13 05:18:25 -05:00
Author
Owner
Copy Link

@ahmafi commented on GitHub (Jul 31, 2025):

Another thing that comes to mind is that a random value is not really good for indexing, something like a uuidv7 would be probably better. Maybe when it's available in more providers, it can be the default value. Postgres 18 added uuidv7 recently.

<!-- gh-comment-id:3140472260 --> @ahmafi commented on GitHub (Jul 31, 2025): Another thing that comes to mind is that a random value is not really good for indexing, something like a `uuidv7` would be probably better. Maybe when it's available in more providers, it can be the default value. Postgres 18 added `uuidv7` recently.
GiteaMirror commented 2026-04-13 05:18:26 -05:00
Author
Owner
Copy Link

@KazimirPodolski commented on GitHub (Jul 31, 2025):

In this case, it's more about the probability of generating the same random value twice and depending on how you configure our generator, it can actually offer higher entropy than UUIDv4 for the same length.

Sorry but that's just not how it works. You'll need to prove that and if you try, you'll find it much much harder that just a line of thought. But I'm not ready to argue that far, please feel free to close the issue if you won't have an action.

<!-- gh-comment-id:3140481921 --> @KazimirPodolski commented on GitHub (Jul 31, 2025): > In this case, it's more about the probability of generating the same random value twice and depending on how you configure our generator, it can actually offer higher entropy than UUIDv4 for the same length. Sorry but that's just not how it works. You'll need to prove that and if you try, you'll find it much much harder that just a line of thought. But I'm not ready to argue that far, please feel free to close the issue if you won't have an action.
GiteaMirror commented 2026-04-13 05:18:26 -05:00
Author
Owner
Copy Link

@kevlened commented on GitHub (Jul 31, 2025):

@KazimirPodolski It’s trivial to show a higher entropy for the same string length, because the character set of uuid is case-insensitive [A-Z0-9], whereas the character set of the custom id is [A-Za-z0-9]. This doesn’t include the extra hyphens in uuid.

As for the randomness, the utility uses a very common secure sampling method. Additionally, there are tests in the utility library to test for bias: 67e06576b8/src/random.test.ts (L145)

If you’re unhappy, you’re free to generate your own ids, but it’s alarmist to categorize this as a critical security issue.

<!-- gh-comment-id:3140674873 --> @kevlened commented on GitHub (Jul 31, 2025): @KazimirPodolski It’s trivial to show a higher entropy for the same string length, because the character set of uuid is case-insensitive [A-Z0-9], whereas the character set of the custom id is [A-Za-z0-9]. This doesn’t include the extra hyphens in uuid. As for the randomness, the utility uses a very common secure sampling method. Additionally, there _are_ tests in the utility library to test for bias: https://github.com/better-auth/utils/blob/67e06576b8504331fcc9cf51479719ce4fc6db24/src/random.test.ts#L145 If you’re unhappy, you’re free to generate your own ids, but it’s alarmist to categorize this as a critical security issue.
GiteaMirror commented 2026-04-13 05:18:27 -05:00
Author
Owner
Copy Link

@amlcx commented on GitHub (Aug 16, 2025):

Although this is already closed, I think @ahmafi 's comment is worth considering. I understand the motivation for a random string unique ID, but having an UUID (especially version 7) would improve several areas; one of them: sorting and cursor-based pagination, which is arguably more efficient than offset-based pagination. Nonetheless, since rolling our own IDs is always an option, creating a new issue might be unnecessary.

<!-- gh-comment-id:3193756671 --> @amlcx commented on GitHub (Aug 16, 2025): Although this is already closed, I think @ahmafi 's comment is worth considering. I understand the motivation for a random string unique ID, but having an UUID (especially version 7) would improve several areas; one of them: sorting and cursor-based pagination, which is arguably more efficient than offset-based pagination. Nonetheless, since rolling our own IDs is always an option, creating a new issue might be unnecessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#9681
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?