zlacker

>>gregor+(OP)
Shouldn't they really have asked it to read https://developers.cloudflare.com/workers/examples/protect-a...

>>ZiiS+cd
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+Js
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+4O
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+xQ
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.