Author Topic: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences  (Read 9573 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

That's the thing, you aren't trusting the client to verify itself. One client is always verifying another client. When I want to upgrade, I obviously already trust my existing client (call it client A). I want to upgrade to the next version (client B). So I use my trusted client A to verify the installer for client B. If that verification passes, I can use the installer to upgrade client A to client B. Now I can repeat the process again using the now trusted client B for any future upgrade to say client C.

Assuming you had some other way (not the way I proposed) to verify client A (or really any client that is first being installed by a user on their computer with no other clients available to verify), then the chain of trust makes this upgrade process secure. I prefer that it be done this way rather than expecting the user to manage tools like GPG and storing the public keys of trusted community members manually, because it is far easier for the user to just remember the human-memorable names of trusted community members ('bytemaster', 'toast', etc.). The validating client could also flag whether the signing names are not included in the user's favorites to prevent against phishing attacks.

Offline theoretical

How about the password entry be through their smart phone which connects to the client somehow?

This isn't a viable approach.  The problem of securing two devices and the connection between them is clearly harder than securing a single device.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical


When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

He's trusting v0.4.22 to verify the hash of v0.4.23 is signed by known key(s).  Which is legitimate.

If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer

Only whoever compiled a given binary version really knows what source code went into that version.  We need to set things up so that every delegate can compile his own version from source and all get the same binaries.  This will require some work though.  So for now we should encourage everyone to compile from source (especially delegates), and sign binaries with a single key for people who insist on using them.
« Last Edit: October 29, 2014, 11:19:42 pm by drltc »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit

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.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.

How about the password entry be through their smart phone which connects to the client somehow?
They enter the password on their smart phone so that it is keylogger proof?

I'm not sure how to set this up yet but I think Trezor has an interesting way of doing thnigs.

https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline theoretical

- the internationalization is not complete (chinese interface), only the messages from web wallet is translated
- messages from bitshares core program is not translated
- messages from qt framework is not translated
- e.g., main menu,  status bar in the bottom
- e.g., 'Block are synced' should be shown as '區塊已經同步完成'

Where are you seeing messages from BitShares core and qt framework?  Screenshots might be helpful.

Chinese locale is available at https://github.com/BitShares/web_wallet/blob/master/app/static/locale-zh-CN.json and a directory listing of other translations is available at https://github.com/BitShares/web_wallet/tree/master/app/static

If you have additional translations, the best way for us to receive them is pull requests to the above Github repo.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

I'm not even saying multiple hashes being posted have to be signed with pgp etc.  They just need to be posted in separate places through separate channels that are known. 
I speak for myself and only myself.

Offline theoretical

- if the installer detected that there are partitions other than c drive, the default path of wallet data should not be in c drive

I disagree.  On a typical system, a drive letter other than C: might be a recovery partition, an optical drive, a network drive or a removable USB drive.  Installing to any of these by default would be a problem.  If a user is technically un-sophisticated and goes with the default, then C: drive is most likely the right place.  If a user is technically knowledgeable enough to have multiple partitions / drives, then they will be technically knowledgeable enough to decide which drive they want to install it to, and change the installation path from the default.  (And I agree with you that it should be possible to change the installation path in the installer.)

If we install to the same partition as Windows by default, it makes sense:  (1) Users expect it because that is the default behavior of most programs, and (2) The Windows partition is likely to be a partition on a local SATA hard drive.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

- If 64bit installer is still unstable, please address this point so that users can make their choice.

Are there specific issues with the 64-bit installer?  Can these crashes be reproduced?  Is the issue discussed in any other threads?
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag

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.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.

No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
 +5%

very good points. i go along with your improvments, i would like to see to choose a different wallet path with installation. i run 2 times in disc overflow and i have no idea why it happened. scared the shit out of me. I am running the OS on a smaller SSD, so i would prefer to place the wallet on a different drive.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

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.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.
I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.


Offline sschechter

  • Sr. Member
  • ****
  • Posts: 380
    • View Profile
Numbers 1 - 3 could be done by a dev-ops engineer, without sucking up the time of our core blockchain developers.  I would like to see this person hired with AGS funds, it is long overdue.
BTSX: sschechter
PTS: PvBUyPrDRkJLVXZfvWjdudRtQgv1Fcy5Qe

Xeldal

  • Guest
 +5% Great work. Excellent suggestions.

Quote
Suggestions:
- installer can let users to choose the path of wallet data
This has always bugged me.  Damn near all wallets lack this.