4

I generate oauth2 access and refresh tokens and store them in my database. I generate these tokens using UUID v4 and remove the dashes. I used to delete the tokens after they expire but now I store all of them because I thought of something that could happen.

What if an attacker stored locally all of the access tokens that were generated for him and he kept using these access tokens again and again for authorization. Since I, as the DB admin, was deleting the generated tokens, the DB has no way of knowing that the token is unique. Therefore if the UUIDv4 algorithm generates an access token for a different user and it's a collision (same UUID as one generated previously) and the attacker found that collision, he could get into the service since he has the tokens that have been generated before.

My question is should I worry about this and keep all my tokens in case of collision to check for uniqueness or should I delete the access and refresh tokens after they expire and trust that UUIDv4 has enough entropy to prevent this?

I'm also worried that if I keep all the tokens, it's going to inflate the database since the access tokens expire every hour and are regenerated the next time the user takes an action.

Any help is appreciated!

Shaun the Sheep
  • 22,353
  • 1
  • 72
  • 100
programmerdave
  • 1,088
  • 1
  • 9
  • 17

1 Answers1

2

Though there is a minimal chance of UUID collisions in theory, the whole point of UUIDs is to be unique in practice, just consider the name "Universally Unique Identifier". For calculating the chances of a collision, see e.g. this link, I wouldn't sit and wait until it happens. ;-)

I don't expect that you generate enough UUIDs for a realistic chance of even a single collision. If you still do so, storing that many access tokens in a database might also be a problem, it might need huge storage. If you still afraid of collisions, I suggest generating something even more unique than UUIDs, but avoid storing all of them in your database.

Zólyomi István
  • 2,401
  • 17
  • 28