zlacker

Shouldn't they really have asked it to read https://developers.cloudflare.com/workers/examples/protect-a...

>>ZiiS+(OP)
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+xf
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+SA
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+lD
Yes I guess if you trust the hash implementation completly; I just favour a bit more defence in depth.

>>kenton+lD
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.