You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is maybe a nitpicky edge-casey problem but i think its worth being aware of.
Removing permissioned access mode means we use no longer control rate limiting on a per-user basis. We use the public verifying key rather than the signature request key in order to track how many requests have come from a single account.
This should not be a problem, since the rate limit counter only gets incremented after the signing protocol has run, which means a request which does not result in a successful program evaluation never counts towards the rate limit. So we can still have per-user rate limiting by implementing permissioning within a program.
However, with program-based permissioning it is impossible to protect against replay attacks. That is, given a message and a signature made with the public key from a permissioned program's configuration, one can repeatedly run the program successfully, and therefore repeatedly run the signing protocol and increment the rate limit counter.
This was previously impossible with permissioned access mode because of the timestamp checks. We cannot implement nonce or timestamp checks in programs because they do not hold state or have access to the system clock.
So what i'm saying is - with permissioned programs, any signed message made with the keypair used for in-program authentication must be kept secret, as it could be used to maliciously block the account by repeatedly signing the same message and activating the rate limit.
The text was updated successfully, but these errors were encountered:
This is maybe a nitpicky edge-casey problem but i think its worth being aware of.
Removing permissioned access mode means we use no longer control rate limiting on a per-user basis. We use the public verifying key rather than the signature request key in order to track how many requests have come from a single account.
This should not be a problem, since the rate limit counter only gets incremented after the signing protocol has run, which means a request which does not result in a successful program evaluation never counts towards the rate limit. So we can still have per-user rate limiting by implementing permissioning within a program.
However, with program-based permissioning it is impossible to protect against replay attacks. That is, given a message and a signature made with the public key from a permissioned program's configuration, one can repeatedly run the program successfully, and therefore repeatedly run the signing protocol and increment the rate limit counter.
This was previously impossible with permissioned access mode because of the timestamp checks. We cannot implement nonce or timestamp checks in programs because they do not hold state or have access to the system clock.
So what i'm saying is - with permissioned programs, any signed message made with the keypair used for in-program authentication must be kept secret, as it could be used to maliciously block the account by repeatedly signing the same message and activating the rate limit.
The text was updated successfully, but these errors were encountered: