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

0 Members and 1 Guest are viewing this topic.

Offline theoretical


I've put most of the suggestions in this thread in various tickets, there is a list here:  https://github.com/BitShares/qt_wallet/issues/62

There is some public discussion of these suggestions in the individual tickets linked in that ticket.  Specific, actionable feedback is always appreciated.
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

- the fields for entering passwords in lock screen should be anti-keylogger

I don't think there's anything we can do to protect users when their workstation has been compromised to that extent.  If you have a specific anti-keylogging mechanism in mind, more details will allow a more specific analysis.
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 liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
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.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .

We have been through this discussion before on this forum. Two factor authentication is no good without multisig if you are trying to protect against attacks where your computer is compromised (which would have to be the case if a keylogger is running on it). This is why multisig is so important. Once that is built and there are companies to support, multi-factor authentication mechanisms can actually provide security.
what about a combination with yubikey ?

Sent from my ALCATEL ONE TOUCH 997D


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?

The easiest thing to do would be to just rely on HTTPS. Yeah, the user could be at a risk of a man-in-the-middle attack, but the risk is only for that one time they download the installer for the first time.

More advanced users could use GPG to verify that the hash of the installer is signed by the appropriate trusted developers and auditors. Obviously you need to somehow get the public key fingerprints of these people to know you have the right public keys (they could read the fingerprints aloud in a YouTube video for example).

You could also read the hash of the executable over the phone to a few trusted friends (or if not trusted, at least friends who you are confident wouldn't collude together to harm you) who already have the blockchain clients setup and ask them to use their client to verify that it is valid.
key signing party in mumble! .. yhea ... i'd love to have a signature of BM in my keyring :)
though a trusted signature requires a physical meeting .. (IMHO)

however, in GPG there are different kinds of "trust" when signing keys .. so seriously, why not organize a key signing party?
BM could make a photo/video of him holding up the fingerprint .. and most of us know the voice of BM pretty well already to accept making a minimum-trust signature

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?

The easiest thing to do would be to just rely on HTTPS. Yeah, the user could be at a risk of a man-in-the-middle attack, but the risk is only for that one time they download the installer for the first time.

More advanced users could use GPG to verify that the hash of the installer is signed by the appropriate trusted developers and auditors. Obviously you need to somehow get the public key fingerprints of these people to know you have the right public keys (they could read the fingerprints aloud in a YouTube video for example).

You could also read the hash of the executable over the phone to a few trusted friends (or if not trusted, at least friends who you are confident wouldn't collude together to harm you) who already have the blockchain clients setup and ask them to use their client to verify that it is valid.

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?

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.

So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?
I speak for myself and only myself.

Offline 029xue

  • Full Member
  • ***
  • Posts: 142
    • View Profile
According to i3's production rate, I would say this is not an easy work...

Offline 麥可貓

  • Sr. Member
  • ****
  • Posts: 267
    • View Profile
- 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.

translation of locale-zh-CN.json has been completed. the problem is the remaining part.
PTS: PmRVDPymZqSAZEXauHZSewrUrE66af7epT
BTSX: michaelcat
Delegate Team: x1.sun  x2.sun

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
MUSE witness:mygoodfriend     vote for me

Offline mint chocolate chip

- 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?

I just installed the latest 64 version over the top of an existing version yesterday and got an error message at the end of it. Even though it closed because of the error, when I opened the software it worked fine. It automatically created an error file that was sent.


I would add to the suggestions is to start dropping the X in BitShares X. I see it everywhere and those X's need to be gone in a week, might as well start phasing them out now.

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
- 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.

Whie d drive may be recovery partition, optical drive, usb drive as you said, c drive could be formatted while re-installing OS. Furthermore, current default data-dir path is in a hidden folder, which normal users doesn't regularly backup. At least I think it should be at some places that users can see and regularly backup.
« Last Edit: October 30, 2014, 04:40:42 pm by cn-members »
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
- 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?

e.g., sometimes in 64bit wallet, after you entered your password in lock screen, the unlock button doesn't work. So you have to restart wallet.
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

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?

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.

Oh I see, you're using a chain of installers.  So instead of a blockchain we have an installerchain. :) That is a very interesting idea.  Just have the wallet be able to verify the hash of any arbitrary executable.  Likely not that hard once we get keyid etc in place.

Honestly I was wondering how you could think an intaller could verify itself.  You seem to be a person with some of the better (best?)  ideas so I was at a loss. :)
I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .

We have been through this discussion before on this forum. Two factor authentication is no good without multisig if you are trying to protect against attacks where your computer is compromised (which would have to be the case if a keylogger is running on it). This is why multisig is so important. Once that is built and there are companies to support, multi-factor authentication mechanisms can actually provide security.

Offline jamesc


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.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .