How many tokens might we have in circulation at any time? Again, it is helpful to consider extremes.
After all, this is clearly possible with current technology and will only improve over time. But it is worth considering the extremes. It’s fairly unlikely that anyone would direct that amount of resource at breaking your site’s session tokens, and you can use rate limiting and other tactics. When I looked back in February (you can see how long my blog queue is!), the maximum rate was around 24293141000000000000 hashes per second, or around 2 64. A lot of people are investing a lot of time and money into generating random hashes, and we can view this as roughly equivalent to our attacker’s task. When we consider how fast a well resourced attacker could guess a token, we can use the Bitcoin hash rate as a reasonable upper-bound approximation. But what are reasonable numbers? Well, for security we usually want to push the numbers well beyond what we think is actually possible to be really sure. Let’s plug in some numbers and see what we get. Given these parameters, OWASP give a formula for calculating how long it will take an attacker to guess a random token as: We will label the number of valid tokens in circulation at any one time S. How many tokens are valid at any given time? If you have issued a million active session cookies then an attacker can try and guess any of them, making their job easier than if there was just one.We will label the number of random bits B. How many bits of randomness are in each token? A 128-bit random token is more difficult to guess than a 64-bit token.We will call this rate (in guesses per second) A. How quickly can the attacker make guesses? An attacker that can try millions of candidate tokens per second can find a match much faster than somebody who can only try a hundred.To work out how long it would take an attacker to guess a valid token/cookie, we need to consider a number of factors: Well, even if the attacker only makes a single guess, the probability of guessing a 122-bit random value can never be less than 2 -122, so strictly speaking a random UUID is in violation of the spec. Or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
The probability of an attacker guessing generated tokens (and otherĬredentials not intended for handling by end-users) MUST be less than 122 bits is still quite a lot of random, but is it actually enough? If you are generating OAuth 2 access tokens, then the spec says no: In this note I will describe them and what I suggest using instead.Īs stated on the Wikipedia entry, of the 128 bits in a random UUID, 6 are fixed variant and version bits leaving 122 bits of actual random. However, there are some downsides to using random UUIDs that make them less useful than they first appear.
OFFLINE UUID GENERATOR GENERATOR
Under the hood this uses a cryptographically secure pseudorandom number generator (CSPRNG), so the IDs generated are pretty unique. String id = UUID.randomUUID().toString() In Java and most other programming languages, these are very simple to generate: import This is a 128-bit value formatted as 36 hexadecimal digits separated by hyphens. If you need an unguessable random string (for a session cookie or access token, for example), it can be tempting to reach for a random UUID, which looks like this: 88cf3e49-e28e-4c0e-b95f-6a68a785a89d
0 kommentar(er)
