What meaningfully changes the requirements is that takes many more attempts to brute force an API key because they're longer. I'd consider using a weaker bcryp

What meaningfully changes the requirements is that takes many more attempts to brute force an API key because they're longer. I'd consider using a weaker bcrypt/scrypt/argon2 for API keys than would be used for login. Perhaps one that takes a hundredth or a thousandth of the time. It could be unnecessary though. Here's the main scenario: someone snagged a hashed long token from a database backup and wants to get the unhashed long token so they can use it to access something behind the API. They can do all the brute forcing they want and the server owner will never know about it. There are 1 with 42 zeroes worth of potential long tokens to try (58 * '51FwqftsmMDHHbJAMEXXHCgG'.length). Seems unlikely even though it's very very cheap to hash a potential long token. The tokens this is using are pretty short, but still not short enough to make cracking it feasible. If you used argon2 maybe you could cut mycompany_BRTRKFsL_51FwqftsmMDHHbJAMEXXHCgG down to mycompany_BRTRKFsL_51FwqftsmMDH. Shorter token! I would perhaps make the long token 58 digits long just because it would have more than a googol (10^100) possible values but still be shorter than 80 characters with the prefix and short token, and maybe swap the SHA hashing for a low cost (memory and CPU) argon2. If you wanted to have really short API keys you could get creative with argon2. This is relevant for magic links. https://startdebugging.net/2013/10/counting-up-to-one-trillion/ https://startdebugging.net/2013/10/counting-up-to-one-trilli...