24

We have a REST API that communicates with a mobile front-end. After submitting a one time password, the backend will issue a token (random UUID v4 string) for the mobile app to use as authentication on subsequent requests. The server will store a hashed version of this token in the database with the user.

We want to make sure that authenticating the token takes as little time as possible.

QUESTION
What kind of hashing/encryption is sufficient to store the tokens in the database? Is a fast hash such as SHA256 good enough, or should we use a slow hash such as bcrypt? If using SHA256, do we need to include a salt, since the original unhashed token is just a random 16 byte UUID?

maniciam
  • 343
  • 2
  • 4
  • If you expire those tokens, you don't need to hash them at all. When storing user credentials, definitely use salts, hashes like @Hybrid mentioned. – Pepster Feb 18 '17 at 11:18

1 Answers1

27

TLDR; SHA256 is good enough

To answer this we need to look at why we salt, hash, and use multiple iterations of the hash, in the first place;

  • Why do we salt? To protect users that have weak password entropy from having their password cracked (e.g. rainbow tables or two users with the same password). This is not an issue because UUID4 will have 122 bits of entropy1.

    If we wanted to create a rainbow table of all UUIDv4 values that have been SHA256 hashed and we could do 1 trillion hashes a second2. It would take 168.6 quadrillion years to make the rainbow table. So we don't need to worry about that.

  • Why do we hash? To prevent clear text copies of the password from being stored. This seems like a good idea. You don't want someone who can read your database3 to be able to impersonate users.

  • Why do we use multiple iterations? To slow down brute force attacks. As mentioned before UUID4 will have 122 bits of entropy. Cracking these hashes is infeasible even at high speed.

[1] 128 bits - 6 bits that are predetermined

[2] The current fastest hashing rates are chaining all the time so I won't bother trying to find the most current speed it will be out of date in a few months.

[3] This could be SQL Injection, or a leaked copy from a backup, or an insider, or whatever.

Hybrid
  • 4,178
  • 2
  • 21
  • 23
  • 1
    Thanks for this @Hybrid. So for our case, you think SHA256 with one iteration of hashing is sufficient? – maniciam Feb 14 '17 at 16:41
  • 6
    That's correct. Although I should stress for people that may read this in future that SHA256 is good enough *in your specific case* because you are hashing high entropy values and shouldn't be used for anything the user can actually set themselves (like a password). – Hybrid Feb 15 '17 at 02:58