Prevent replay attacks?

[ttmc]

If a man-in-the middle (MITM, an eavesdropper) records a transaction as it travels from a client to a node, it can re-send that transaction to the federation over and over again (even if it's encrypted). This is a so-called "replay attack." It doesn't require the MITM to have a valid private key.

Analysis

• If the transaction is a transfer transaction, then only the first copy can spend the asset. The rest will look like double spending attempts and they won't validate.
• If the transaction is a creation transaction, will each copy create a new asset? It seems to me that they'll all have the same id/hash (even if they're sent to different federation nodes). If a transaction with the id/hash is already in the backlog, a second one with the same id (primary key) can't be inserted. There's another issue When validating a transaction, check to ensure it isn't a duplicate #131 to check for duplicate transactions in the bigchain table (as part of tx validation).

Please keep this issue open as something to re-check from time to time, at least for now (while things are still changing).

[ttmc]

Note: A common solution to prevent replay attacks is to add a "sequence number" to each transaction from a given public key. The sequence number must increase by 1 with each transaction from that public key. Checking the sequence number becomes part of transaction validation.

While a sequence number doesn't seem necessary to prevent replay attacks (see above), it may be used as a way to prevent reordering attacks. See issue #345

[r-marques]

I think that the easiest way would be to just check for duplicated txids

[ttmc]

@r-marques Yes, and duplicate transactions will be checked-for once issue #131 is resolved. I'd like to leave this issue open to be revisited from time-to-time, until the core code is more stable.