> [...] you don't actually need to verify agains a user's secret immediately, you simply need to check that the token is valid using the app secret. The subset of valid tokens that you need to check is much smaller than the universe of all the unexpired tokens your application has issued.
What you are describing here is different than what is described in the blog post that you linked to.
Please look at the definition of the function 'validateToken'. In particular, notice how 'getUser' function (which the author notes issues a DB query) is called for every JWT with a valid signature!
EDIT: I failed to realize that you are the author of the blog post. Still my point stands, in that your description doesn't match what the code does.
> I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence.
From what I've read, there is still lots of unknowns about the scope of the problem. What has been uncovered so far indicates it involves bypassing authentication in SSH.
> If this payload is loaded in openssh sshd, the RSA_public_decrypt function will be redirected into a malicious implementation. We have observed that this malicious implementation can be used to bypass authentication. Further research is being done to explain why.
Thus, an attacker maybe could use this to connect to vulnerable servers without needing to authenticate at all.
What you are describing here is different than what is described in the blog post that you linked to.
Please look at the definition of the function 'validateToken'. In particular, notice how 'getUser' function (which the author notes issues a DB query) is called for every JWT with a valid signature!
EDIT: I failed to realize that you are the author of the blog post. Still my point stands, in that your description doesn't match what the code does.