My goal is to associate (authenticate) hardware devices to users in the database. The access token is generated via webinterface. It is then entered into the hardware device by the user, and the device uses it to authenticate to the webserver. The token is 20 digits random hexadecimal characters and can be revoked. The maximum number of devices is estimated to be 1 million.

Is there any reason, why the user should also enter a userID to the device? Or is the access token sufficient?


3 Answers 3


Without an userID attacking your system can be done a million times faster than with userID. That seems like reason enough to me.

With an userID an attacker can only attack one token at a time. Without userID he can with one try attack all 1 million at once.

  • even so, why not make the access token just 10^6 combinations longer? That is even more randomly distributed, and reduces the complexity of the user interface on the device. Nov 23, 2014 at 11:55
  • When you do so you have effectively introduced an userID. You just happen to store it as the last 6 bytes of your expanded token.
    – Jeff
    Nov 23, 2014 at 13:52
  • Thank you, so I guess the answer is, there is no reason to have a dedicated userID (which has even far less entropy than a random string) Nov 27, 2014 at 7:34

The "userID" you intend to introduce sounds like a second-factor authentication.

So in order to access your system, an adversary needs to possess the device and also needs to know the user ID associated with the device.

It adds a second layer of security, provided that the user ID is not printed on the device itself. Whether it is sufficient depends on the value of the target you are protecting and the threat agents associated. Increased security comes at a greater inconvenience since all your users need to perform an additional step to get access.

Ultimately, you need to find a balance between convenience and security that you are comfortable with.

  • I edited my answer, to show, that the token is basically stored/known/checked by the same parties and therefore definitely not a second factor. Other than that, thanks for the insightful explanation. Nov 27, 2014 at 7:32

I thought I would clear the air for anyone who reads this in the future. The issue with access token only is not the entropy. It is that it makes it much easier to exploit a vulnerability using a timing attack.

An example of this would be if your application looks up the access token directly from a database call where access_token = ''. This is not securely compared, but instead will return as quickly as possible. Thus, will allow an attacker the opportunity to build their strings based on the timings of the comparisons they are sending. There are ways to mitigate this vulnerability, such as always waiting for the same period of time prior to returning the result.

Summed up, the good part about sending a user_id as well, is that you can loop over all that user's tokens and check if any of them match using a secure compare. Which in turn, doesn't give an attacker any useful information for future probes.

  • Good point, I hadn't thought of this. I am not working on this problem anymore and don't remember the specifics. But couldn't the userId itself also be a vulnerable information to a timing a attack? I mean, couldn't the attacker find out easily whether a specific user exists in the db? Jan 29, 2018 at 17:13
  • Yes, an attacker would be able to find out if a user existed based on their id. I cannot think of a reason that would be a security issue. For example, you can find any stack exchange user by ID just by searching the profile page. An example being user of ID=2. security.stackexchange.com/users/2 Jan 29, 2018 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .