14. Fixing replay attacks

This is an advanced exercise. If you're not up for it you can skip this one, although we promise it'll be lots of fun.

There is a security issue with the solution from the previous exercise. Basically, an attacker can intercept a message to the bank (like a withdraw command) and send it to the bank more than once. This is called "replaying" a command. Our current bank will accept the same command over and over again, each time thinking it is valid.

Again we can re-use the hash-chain data structure from a previous exercise to solve this.

Problem

Expand the bank.js program to return the latest hash of the item in the transaction log the customer last appended, every time the customer does an operation (except for register of course since that would always be the first operation).

Have the teller.js store the latest received hash and include this hash as another value in the message that is signed and sent by the teller. That way bank.js can verify the order of a message received from teller.js is correct and not being replayed. A replayed message will include the hash from 2 or more transactions ago, not the last transaction.

Testing

Try recording a deposit message from the teller and send it multiple times to the bank. The bank should reject any replays.

Continue to problem 15