Prevent Brute Force on a Token

[mds1256]

I am working on a simple authentication system and something has came to light regarding the access token and potential brute force.

For the access token there is an expiry date/time where the client will need to send a refresh token to get a new access token.

However, what is stopping an attempt to run a brute force attack against an endpoint and firing lots of random values for the access token?

I know it will be a guessing game but potentially if you have a few million users all with valid tokens then there is a possibility that it could guess it after a few days/weeks of trying?

[ginerjm]

I would think that your access token with an expiration date would in fact become invalid (missing?) by the time a single user manages to guess the answer and that your script would check to see if that access token is present at that point.

[mds1256]

7 minutes ago, ginerjm said:

I would think that your access token with an expiration date would in fact become invalid (missing?) by the time a single user manages to guess the answer and that your script would check to see if that access token is present at that point.

Yeah but if the brute force attack was just changing the access token incrementally then it 'may' stumble upon a working token value?

[ginerjm]

The user is changing what he submits, not your saved cookie that contains the true token that you are comparing the user input against.  And if that token had a lifetime of 10 minutes, the user would have to submit a correct answer within that time.  If your key value was 10-12 chars I would surmise that it takes a healthy number of attempts to 'guess' the correct value within that time frame.   How many times can you press enter within 10 minutes? 

At this point I want to clear something up.  Is this 'access token' something that you send out each time with a new value?  Or is it the authorization token that you create when you log somebody in?  Two different things in my definition book. 

[mds1256]

21 minutes ago, ginerjm said:

The user is changing what he submits, not your saved cookie that contains the true token that you are comparing the user input against.  And if that token had a lifetime of 10 minutes, the user would have to submit a correct answer within that time.  If your key value was 10-12 chars I would surmise that it takes a healthy number of attempts to 'guess' the correct value within that time frame.   How many times can you press enter within 10 minutes?  

At this point I want to clear something up.  Is this 'access token' something that you send out each time with a new value?  Or is it the authorization token that you create when you log somebody in?  Two different things in my definition book. 

Hi

It is an authorisation token which is sent to the user once (when they login and then only when it expires and they get a new token after it has refreshed).

a Worked example might be:

User auth token: cb1d797808ad9cd9a67e6657398b9199 with an expiry of 15 minutes and has only just logged in

The brute forcer is currently running an ongoing incremental attempt and is up to cb1d797808ad9cd9a67e6657398b9191 - (8 more attempts to get to a valid token) So because it will get to the correct value in 8 more goes which takes seconds to try then it will stumble upon a valid token which they can then use for another 10 or so minutes.

 

[kicken]

The answer to this is two-fold.

1) Make sure your tokens are random and long.  This makes the likelyhood of guessing a token so small it may as well be considered impossible.

2) Have a monitoring system in place that can detect a potential brute-force attempt and ban the source IP address.

 

I suspect, like many do, you're under-estimated just how long such a brute-force attempt would take.  Lets take your example and assume a fixed 32-character hex value with the attacker starting at 00000000000000000000000000000000 and working toward ffffffffffffffffffffffffffffffff.  Assuming they have a great connection and your server has a great response time permitting a guess every 1ms, by the time they got to the value cb1d797808ad9cd9a67e6657398b9191 they would already have been guessing for 8,561,210,154,550,000,000,000,000,000 years (if my math is correct, no guarantee there).

Sure, there's a chance they happen to guess one just after it was created along the way, but that chance is tiny.  Hopefully before that happens you've realized what is going on and blocked them via your monitoring system.