1. While releasing new version of BTS wallets
Current Status:
- Because of the 'special networking environment',
the downloading speed of github could be extremely slow or unstable
- The downoaded files could be broken if the network is untable
Suggestions:
- While new versions of BTS wallet binaries is released,
their SHA checksums should be posted in github site at the same time
- people in china can share with each other
- I3 or some of us can setup mirror sites
- files can be easily downloaded and check the SHA checksum posted in the github, so we can make sure that files are not modified/broken
- While the built-in function of wallet detects a new version of wallet,
it should also provide the link to BTS wallet download page, so we can conviently check the changelog and download new binaries.
I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.
6. GUI Security
Suggestions:
- the fields for entering passwords in lock screen should be anti-keylogger
- the commands/operations should be divided into 2 categories: commands that moves funds or operate private keys and etc. For commands that moves funds or operate private keys,
another 'transaction password', which is different from wallet password,
should be entered to execute these commands.
- For transaction password: 1) transaction password has to be different from wallet password. 2) this can avoid private being buffered in ram continuously, the private key should only be extracted for short term while the transaction password is provided. 3) to maintain convenience, small payouts (the limit can be customized) can be executed without passwords, but the total amount of small transaction per day should be limited (just like VISA)
I seriously question any value of a mouse-based password entry system since if your machine is compromised enough to have a keylogger on it than you should assume it will be able to get your private key one way or another (even if it requires replacing the BitShares client with a fake one that phones home).
For a full client you need to keep the private keys in RAM because of how TITAN works. However, once lightweight clients are ready, I can see a lot of value in two different passwords. The "transaction password" would be what is considered the wallet password today. The "wallet password" would be a new password that serves three functions: it decrypts the data stored on the computer that would be considered plaintext in the exported wallet JSON file (and also any new exported wallet files would be an encrypted blob of the JSON using a key derived from the "wallet password"); it unlocks the GUI; and, it derives the keys used to decrypt KeyMail messages. The client would prompt the user for the "transaction password" (which would be used for its purpose and then discarded from memory) anytime the user needed to do something that required their account private key: signing a transaction (in order to send money, place bid/ask/short orders or remove them, cover shorts, update Key Graph, etc.) or decrypting received funds that were notified by KeyMail. This means that if the GUI was "locked" but running and a user at the computer did not have the "wallet password", they would not be able to even snoop on the amount of funds the computer owner owns or their transaction history, but the wallet could still be running (keeping in sync with the network, keeping up to date with the latest block headers and set of active delegates, listening for any income messages from KeyMail). On the other hand, if the GUI was running "unlocked", then a user at the computer would be able to see transaction details and account balances but they would still not be able to steal funds from the computer owner. The notifications sent through KeyMail (notifying of new incoming funds, notifying that orders were matched, or simply a message sent by some account) would instead be encrypted using the public key derived from the "transaction password" + salt (which would be published on the blockchain) so that the in-memory private key derived when the user first ran and unlocked the GUI client could be used to automatically decrypt and process the KeyMail messages in the background and optionally notify the user through desktop notifications.
The third item you list could be accomplished by using a separate account for the small amount of funds whose private key is derived from the "wallet password" rather than the "transaction password", but personally I think it makes more sense to just implement that functionality through multisig instead. There would be some other company on the other end providing one of the keys of the 2-of-3 multsig. They could then create all kinds of interesting policies where the strength of your authentication proof would depend on your spending habits.