Differential D6836
[identity] add nonces table to dynamoDB Authored by varun on Feb 22 2023, 10:08 AM. Tags None Referenced Files
Subscribers
Details
clients signing an ETH message need a recent nonce in the message. they will query the identity service for a nonce, which the identity service will persist, along with its creation time. we need a new DDB table for the nonces, which we'll provision with terraform. terraform validate && terraform plan
Diff Detail
Event TimelineComment Actions I have no idea how to interpret this syntax... maybe @jon knows or can get up-to-speed on it? Comment Actions basically, we are provisioning a table called identity-nonces. the primary key (hash_key in terraform) is the nonce, which is a string type (S). we set the max number of reads/writes per second to 10 (a little arbitrary but consistent with the rest of the tables right now, we can adjust later if needed) Comment Actions Looks similar to other tables, so the syntax looks okay. My main concern is data modeling. The nonce should probably be related to a userID or public key. Otherwise there's no way to relate a nonce to an on-going exchange. Unless I'm missing something. Comment Actions @atul and I had to deal with the same question when designing this on the keyserver side. General conclusion is that it probably isn't super important to associate a nonce with a specific session in this specific case. A sufficiently random nonce is impossible to guess, and so can be thought of its own "password". So the only point of having the service check a second thing (a session D) would be to protect against a scenario where the client has an exploit and an attacker is able to read the nonce. But in that scenario, wouldn't the attacker also have access to the session ID? It matters in a web browser environment, where the session ID can be harder to compromise than the nonce. Browser session IDs are generally stored in an HttpOnly cookie, so JS exploits might not be able to get to it even if they are able to get to the nonce. On the other hand, if the session ID is being passed via gRPC param (rather than by a Set-Cookie HTTP header), we would have to have access to it in JS anyways... so there's not really any security benefit. Comment Actions
RE this, the nonce table should be modeled as a set of keys. The API will query for the nonce to see if it exists in the table. If it exists, it will succeed and delete the entry. If the nonce isn't in the table, the API will fail. Comment Actions
Kind of an implementation detail, but found that the cleanest way to approach this on the keyserver side was to have a single DELETE query and to check affectedRows from the query result:  (siwe-nonce-deleters.js) Comment Actions Seems like from ashoat's feedback the nonce is similar to a unique token, in which case I think this is alright. |