zlacker

The secret token is hashed first, and it's the hash that is looked up in storage. In this arrangement, an attacker cannot use timing to determine the correct value byte-by-byte, because any change to the secret token is expected to randomize the whole hash. So, timing-safe equality is not needed.

That said, if you have spotted a place in the code where you believe there is such a vulnerability, please do report it. Disclosure guidelines are at: https://github.com/cloudflare/workers-oauth-provider/blob/ma...

>>kenton+(OP)
I am not confident enough in this area to to report a vunrability, the networking alone probably makes timing impractical. I thought it was now practical to generate known prefix Sha256, so some information could be extracted? Not enough to compromise but the function is right there.

>>ZiiS+ll
Learning a prefix of the hash doesn't really get you anywhere. The hash itself isn't a secret -- it could be published publicly without breaking the security model. You still need to derive a token that hashes to that value in full, and if you can do that then you've broken the hash algorithm by definition.

>>kenton+On
Yes I guess if you trust the hash implementation completly; I just favour a bit more defence in depth.

>>kenton+On
Say I got a memory dump from the client system. I don't know what is what but the secret is in their somewhere.

Filtering it down by the hash prefix locally is much leas likly to be detected then spamming the servers.