Secure Transaction Signer

Parity 1.2 and above comes with the experimental Secure Transaction Signer framework. To ensure this is enabled in Parity 1.2, run Parity with the --signer flag (or use parity ui, which enables it by default). For Parity 1.3, it is enabled by default.

When run with the signer, RPC endpoints that use your secret keys like eth_sendTransaction become privileged and no longer work as before. Instead the transactions gets placed into a queue. The transactions stay in the queue until the user (that's you) either confirms that they should be signed (and possibly provide the password), or that they should be cancelled.

The interface that you confirm or cancel transaction through is called the Signer UI. Parity ships with a standard Signer UI which runs over HTTP. Point a browser to http://127.0.0.1:8180/ while Parity is running and you'll see it. There is also a Chrome Extension which integrates much of Parity including the transaction signer into the Chrome browser.

To prevent Dapps masquerading as Signer UIs, and to prevent Signer UIs from stealing each others unlocked secrets, Parity uses two levels of authentication tokens. When you first set up a new Signer UI you will be asked to input a Signer UI Token to prove that you wish to use this software to confirm transactions for signing. You can get such a key from Parity's output console or by running parity signer new-token. It cannot be automated since it's important that it doesn't happen without your knowledge.

After a Signer UI is set up, it is able to check the aforementioned queue of unsigned transactions and petition the user to sign them, potentially collecting a password. In principle a password only needs to be collected once (though nothing is stopping the Signer UI from requiring it multiple times) since Parity unlocks the secret on a per-Signer UI basis. As an additional level of security, Parity prevents one Signer UIs signing a transaction with a password unlocked from another Signer UI through the use of a rotating secret token. Whenever a Signer UI unlocks a secret, it gets back a token in order to allow it to reuse the unlocked Secret at a later time. Every time it uses such a token, it gets a new one back - by being single-use it prevents any malicious Signer UI (which somehow already got a key to register itself with) from using a password-unlocked secret from another Signer UI, at least without it being obvious that it happened.

With this in place, all you, the user, need to know is that you should only ever enter your password into Signer UI software (e.g. http://127.0.0.1:8180/) - that which you have already given a Signer UI key and which is able to properly show you the transaction which you wish to sign.