docs: add section on replay protection to getting-started #400
Conversation
rflechtner
changed the title
| } | ||
| ``` | ||
|
|
||
| ### 6.3. Replay Protection | ||
|
|
||
| In certain use cases, an attacker may intercept and copy credential submissions traveling from claimers to verifiers in an attempt to convince the verifier to accept the credential submission again later on. |
There was a problem hiding this comment.
Or, the claimer copies the message to give it to their friends.
There was a problem hiding this comment.
yeaaaah, but... if the owner is in on it, they could also just re-submit. It's not like you would alter the origin/sender by giving someone a copy of your message
docs/getting-started.md
Outdated
| if ( | ||
| submissions.has(encrypted.hash) || | ||
| encrypted.createdAt > Date.now() + MAX_ACCEPTED_AGE || | ||
| encrypted.createdAt < Date.now() + MIN_ACCEPTED_AGE |
There was a problem hiding this comment.
| encrypted.createdAt < Date.now() + MIN_ACCEPTED_AGE | |
| encrypted.createdAt > Date.now() - MIN_ACCEPTED_AGE |
Creation date can lie up to 1s in the future
if MIN_ACCEPTED_AGE would be a positive number, this could become a + and would be easier to read.
There was a problem hiding this comment.
it would however clash with the variable name a bit; here, if you set the MIN_ACCEPTED_AGE to 1s, then messages cannot be more recent than 1s in the past (age of 1s), if you set it to -1s, they cannot be more recent than one second in the future.
|
@tjwelde @Dudleyneedham I have "unstaled" this PR so that it can be merged. |
|
This is superseded by KILTprotocol/docs#100 |
fixes KILTProtocol/ticket#1373
Adds a little section on how the timestamps in messages help with replay protection.
Also updates the example on how to remove properties from a credential, which I missed when merging #398
How to test:
Read, understand, complain if you want.
Checklist: