0

I want to figure out how safe is to implement a 15 bytes long password reset token.

If we have 26 letters and 10 numbers, 36 possibilities per byte. And we have a 15 byte long token, that means that the total amount of possibilities is 36^15.

Is it possible to brute-force and find a token in a reasonable amount of time? The amount of possibilities here is really really big, so i don't understand why other websites implement a +32 or +50 byte long tokens.

Can someone explain that and maybe the math behind this to probe if this is possible?

Let's assume we can brute-force at 15k request per second and the token does not expire**

1

Let's say you want to be extra careful and hash the token in case of a database leak (tokens should expire anyway, but maybe some are still valid shortly after a leak). You also don't want to have any useful information in the token since emails aren't difficult to intercept, in fact, you don't even want to have an incrementing reset token id because someone could see how many tokens have been issued (what they would do with that I don't know, but maybe you're a bit paranoid).

So to have some way to tie it to a user while still hashing it, you decide to take a 256 bit value generated by a CSPRNG, split it in half, use the first 128 bits as an identifier, and the 2nd 128 bits as the token. Both halves are included in the reset token url, the database stores the first half in plaintext, and hashes the second half before storing.

So you've got a 256 bit value now, how do you encode it in the url? If you want to only use letters and digits, you'll need ln(2^256) / ln(36) ≈ 49.5, 50 characters. So there you go.

I'm not saying everyone using a long reset token is doing it this way, but this is a reasonable thing to do that would require a longer token.


Does this mean a 15 character token is bad?

Not really. It's only got about 77.5 bits of entropy (assuming it's generated by a CSPRNG, which it needs to be), which is a bit low, but if you're not worried about an offline attack (hopefully your reset tokens are short lived), that's perfectly reasonable. It just means there's also a reasonable way to come up with a 50 character reset token. And really, what do 35 extra characters in a url hurt?

  • let say that the token does not expire, how long would it take for an attacker to find the token? i want to know if this is worth reporting as a security issue. Aparently the token does not expire. – Mr. ToxicMan Sep 22 '19 at 1:36
  • @Mr.ToxicMan That depends how the token is being attacked. In an online attack even 77 bits of entropy should be enough. If the database ends up leaked, how are the tokens stored? If they're stored in plaintext then all of them that are still valid (do they expire or are they deleted after being used at least?) can be used without any effort at all. If they're hashed, how are they hashed? It depends on too many things to say without more info. – AndrolGenhald Sep 22 '19 at 1:44
  • Non-expiring reset tokens would probably be considered a security risk, but depending on the application it could be a very small risk. It's probably worth reporting, but it might not be given a very high priority to fix. See also Are password reset links that don't expire a security risk? – AndrolGenhald Sep 22 '19 at 1:46
  • yea i'm talking about a onlin brute-force attack, not offline attack and no databases leaked, thought a 15 character long would be easy to brute-force but aparently it isn't. i'll look that link, thanks! – Mr. ToxicMan Sep 22 '19 at 1:47
0

At only 15000 requests per second, it would take on average over 200 billion years to randomly guess your token, which would indeed be long enough. However, your estimate of only 15000 is likely way on the low side. lg(36¹⁵) ≈ 77.5, so your token would only have 77.5 bits of entropy. Consensus today is that you really want 128 bits of entropy for security, which works out to a 25-character token, assuming 36 possibilities per character as you specified.

  • 1
    Given that it's a password reset token (which hopefully expires) I would assume OP's threat model excludes offline attacks. This would be good to clarify though. – AndrolGenhald Sep 22 '19 at 0:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.