ask for passphrase during initial setup

[thedavidmeister]

Unencrypted private keys are written to a text file in a known location byteball/Default/Local Storage by default.

This means that if i can get a copy of anyone's byteball wallet backup directory i can simply start spending immediately.

This is a serious problem even if i have multisig setup.

Between myself and my gf i have 4 devices, so i could do a 2/4 or 3/4 setup, but her devices and mine spend a huge amount of time on the same home (relatively unsophisticated) network, and are running essentially the same hardware and very similar software configurations.

It's not unreasonable to assume that anyone who can compromise my device and read text files can do the same for at least one other device on my network, and probably all of them tbh...

Ideally the wallet software should both encrypt highly sensitive data (private keys) and also require multiple signatures by default.

These keys are encrypted if the user creates a password for transfers as part of general settings but the current workflow has serious issues:

• An attacker still has a rather large window of opportunity between when wallets are created and when a passphrase is set to scrape sensitive data from the file system
• none of this is explained in the UI, the settings are hard to find and nothing explains that a "transfer password" = "encryption passphrase"
• if i don't set a passphrase then i can be hacked and lose all my byteball potentially years in the future even if i never use the wallet again, for as long as that text file stays sitting around on my HD somewhere
• actually, the subject of security and the benefits of multisig and passphrases aren't visible anywhere in the wallet app. The functionality exists, but is presented almost as an afterthought, rather than something critically important if you're considering putting significant funds into the byteball network.

My suggestion is:

• Provide the option to set a passphrase before any secret keys are generated by the wallet software. Ideally plain text secret keys never leave the in-memory application state, and are only there for the minimum time required (when the private key is actually used to send transactions to the network).
• Explain that the passphrase is directly used to encrypt the wallet data and so losing the passphrase is just a hop, skip and a jump away from losing your private key
• Ensure/strongly recommend that passphrases are at least 8 characters since the attack scenario of someone copying the wallet data is very brute forceable
• Recommend that users create new wallets when they set a passphrase (every time? initally?) for previously unencrypted wallets as the assumption should be that all existing wallets have compromised keys

[thedavidmeister]

Also maybe explain that losing your passphrase is the same as losing all your money and nobody can recover it for you...

[thedavidmeister]

Actually, i just realised that it's the seed that is being saved in clear text, not just a private key for one wallet, so creating new wallets within the app does nothing to improve security even after I've set a password.

So no matter what I do, using the wallet exposes me to some period of time where an attacker can read my private seed from files on my HD.

[tonyofbyteball]

While security is of utmost importance for a financial app like this, security should match the amounts at stake. Every new wallet starts with 0 balance and the least demanding security settings, the priority here is fast start-up times and smooth user experience. As the balances grow, users should be able to adapt their security settings.

In all financial apps there is always a huge number of conceivable theoretical attack vectors, but only small number of them are being tried by attackers in practice, for the simple reason that the attackers are profit seeking individuals and they know their ROI. Such untargeted attacks as infecting computers with wallet-stealing malware before even knowing that the user is going to install Byteball wallet, seems wildly unpractical to me, at least now when only a few thousand people know about Byteball.

When setting a password, it is actually already said that the key will be encrypted.

In 1.9.2:

• added a welcome message for new users suggesting to set a password
• added reminder to delete the seed when setting a password

[thedavidmeister]

@tonyofbyteball i think i've missed some important info here.

I disagree that a targeted attack towards byteball is required. The private key by default simply lives in plain text in a file in "Application Support" on a mac, alongside many other files containing data for other applications that might be the real target (e.g. a ransomware style attack). Anything that read data from that directory would scoop up byteball private keys incidentally.

Regardless, let's assume that i do have a large amount of money at stake and i'm willing to do a little extra work for protection (which I am 😄 ). What are the basic steps to create a wallet without the private key being saved to a plain text file?

[tonyofbyteball]

What we are doing is not much different from other crypto wallets where no passcode is set.

What are the basic steps to create a wallet without the private key being saved to a plain text file?

Set a password and delete the seed and/or use multisig. Multisig is highly recommended as system-level malware can install a keylogger that would catch your password.

[thedavidmeister]

unfortunately "other people do it this way" doesn't mean much when it comes to security. There are also plenty of high profile examples of people (including businesses) losing cryptocurrency due to failing to encrypt data carefully. If anything the number of lost plain text secrets seemed worse to me in the early days of bitcoin because there were essentially no secure options available at the retail end (no Trezor, etc.) so rather than say "it's fine because it's new" i'd say "it's not fine because people have no good alternatives yet".

Even if i set a password and delete the seed, or use multisig, it doesn't prevent my private seed being exported to disk in plain text before the password is created.

There's no way to generate a new private seed after i set a password and i might not find out that my private seed has been compromised until multiple years in the future, when someone other than myself finally decides to use it.

An alternative option here might be the ability to create new private seeds from the wallet after you have a password setup.

[pwpwpwpw]

I noticed the same thing with linux mint 18.2, I assume all ubuntu and other linux distros do the same as well. I tested light and full clients too, 2 things happen, first of all the password that you request is remembered and automatically filled in when you start the client and it is saved in plain text at ~/.config/byteball/default/Login Data text inside is: "chrome-extension://ppgbkonninhcodjcnbpghnagfadnfjck/public/index.htmlchrome-extension://ppgbkonninhcodjcnbpghnagfadnfjck/public/index.htmlpasswordchrome-extension://ppgbkonninhcodjcnbpghnagfadnfjck/"

BTW the seed in linux is not saved in plain text, only the password.

I tested the exact same steps, install light and full client, request pass, exit, search for pass in all files as text and windows 7 x64 does not save the pass or the seed. I don't use win 10 but someone can test the same thing. So this is a bug in the linux/osx, using latest clients version 1.10.

[tonyofbyteball]

@pwpwpwpw please create a separate issue, this bug seems unrelated to this one.

[tonyofbyteball]

An alternative option here might be the ability to create new private seeds from the wallet after you have a password setup.

That would be a good option, pull requests are welcome. It would have a more practical use case when you feel like your keys could be compromised and want to change the keys while preserving everything in the wallet. We have address_definition_change for that. The specific attack vector you describe seems too theoretical.