Wallet check-up via PIN

[arhag]

I understand when you say it's a false sense of security, however, obviously that wouldn't grant the user invulnerability. It would be just a method to prevent some attack methods. Not 100% safe, yeah, I agree with that, but it's still more secure than nothing.

The thing about a false sense of security is that it encourages people to do things they otherwise wouldn't do if they knew what they were doing wasn't secure: for example storing a large amount of money in a wallet that is "secured" by an insecure method. If we could guarantee that the user wouldn't treat the wallet with the virtual keyboard any differently than one without, then sure, it is an improvement in security.

And I understand if someone really values his stake, that person will take all safety precautions possible, however I just cannot see the average joe doing all of that. This would be a simple method for the average person to get a higher level of security, even though that doesn't mean his waller is invulnerable so that should be mentioned, but still, as I want to emphasize, for the average joe, it might be a good method to reduce attacks. I appreciate your input and help very much, but someone new who is just interested in trading will be scared just to look at that wall of text. Sure in the future it might be easier, but if it's not, I just can't see the average person doing that. That's why I suggested the mouse hovering thing, due to being something accessible to the masses, average users, unless the method you mentioned can be simplified of course

Don't mistake the complexity of the implementation (something I went into detail for the wallet designers/programmers) for complexity in the process and UX. Here is the UX:

• You purchase a standard flash drive, a special trusted BitShares flash drive, and a small hardware device (the security token) that you can attach to your physical key chain. Better yet, the small hardware device would also serve double duty as the special trusted BitShares flash drive.
• Plug in the BitShares flash drive and boot the computer off that flash drive. Then, after it boots, also plug in the hardware device and your standard flash drive.
• The UI will prompt you whether you want to sign a transaction, transfer all funds to a new account, reset the security token, or create a new account. You choose "create a new account".
• The UI prompts you to enter in a strong master passphrase and a simpler wallet passphrase. It also asks you to choose the location on your standard flash drive to save the data to.
• You press submit, you retype your master passphrase and wallet passphrase to prevent typos, hit confirm, and the application writes data to the standard flash drive and the security token. It also displays an encrypted brain-key (a sequence of dictionary words) on the screen and asks you to write this down and store it in a safe place.
• After you write down the brain-key, you can shut down the machine and unplug the security token and the flash drives.
• You now take your standard flash drive to your online machine (or restart your computer while booting from its standard OS), and run the light wallet application.
• You click on "Register new 2-of-3 multisig account" in the light wallet UI and it prompts you to point to the location of the saved file on your flash drive.
• You then type in the unique account name you want to register on the blockchain as well as your wallet passphrase and then press the "Register new account" button. The light wallet tells you that you are successful in registering your new account.
• If after receiving some funds to your new account you want to transfer it to someone else, the light wallet will not only ask you for your wallet passphrase but also the updating one-time code displayed on your security token. Without both, you cannot send any funds.

[Akado]

Not to mention people will feel more secure

Yeah, a false sense of security. As xeroc mentioned, once your machine is compromised, you cannot rely on any of these tricks.

The real solution as usual is: multisig.

The light wallet server can serve double duty as the second signer in a 2-of-3 scheme.

The light wallet server has a public key L and corresponding private key l. Save L to a flash drive that also contains special trusted BitShares tools.

You use an offline trusted computer running a live Linux CD and the BitShares tools on the flash drive to generate a random private key pm (corresponding public key is Pm). Deterministically derive private key pw (corresponding public key is Pw) as hardened child key of pm with index 1 and private key ps as a hardened child key of pm with index 2. Deterministically derive private key ps1 (corresponding public key is Ps1) as hardened child key of ps with index 1. EC multiplication of ps1 and L gives S1. Use your own strong master passphrase m to encrypt pm and represent the encrypted key in brain-key form (passphrase consisting of a sequence of dictionary words) as b. Use your wallet passphrase w to encrypt pw as p. Save b, p,  Pm, and Ps1 to a flash drive (also you can write down b on a paper backup). Plug in a security token to the machine and use the software tools to write S1 into its secure firmware (overwriting any previous secret stored in that location) and also adjust its clock if necessary. Then shut down the offline computer.

Take the flash drive to an online computer with the light wallet (or alternatively to a computer that will let you communicate p, Pm, and Ps1 to your smartphone/tablet via email / cloud / QR code). Let it import p, Pm, and Ps1 from the flash drive (or alternative source) and store it in its local storage. Then it should prompt you for your wallet passphrase w, decrypt p using the w into pw in memory, and then go through the process of letting you register a new account if public key Pw isn't already registered on the blockchain.

You type in the account name you want to use and it tells the light wallet server to generate a new transaction to register that account name to public key Pw on the blockchain, and as a part of its public account record it is specified that it is a public_account, it stores Ps1 as an additional key in the record called the "one-time security public key", and it also specified it wants to receive funds using a 2-of-3 multisig where the three addresses are the ones corresponding to the public keys Pw, Pm, and L. It receives this transaction, signs it using pw, and sends it back to the light wallet server so that the server can also sign it (to pay for its registration fees) and broadcast the transaction.

All funds sent to that account will automatically use that 2-of-3 multisig condition for withdrawal. Those funds could always be spent by the user alone (even if the light wallet server disappears) as long as the user can get access to the encrypted brain-key b (which should be backed up in multiple places including the flash drive, paper backup, and perhaps a cloud service) and knows the master passphrase m. But the usual way those funds will be spent is by signing the transaction with the private key pw that is decrypted in the memory of the light wallet (assuming the wallet passphrase is provided) and by the light wallet server using private key l. For the light wallet server to sign any transaction already signed by pw, it also needs the light wallet to provide a one-time password over their secure connection. This one-time password is deterministically generated from the current time and the shared secret S1 (which the light wallet server can generate using EC multiplication of the known public key Ps1 associated to the account on the blockchain and the server's private key l).

The shared secret S1 is not known to the computer running the light wallet (which is what provides multi-factor security). Instead it should be securely stored inside of the security token. Ideally, the hardware device is designed so that it is difficult to get the secret out of it, but it is theoretically possible to do so if the adversary has physical access to the token. Also, keep in mind that anyone could easily erase the secret if they could get physical access to it even for a short period of time (plus you could lose the device anyway and need to replace it). Whether the secret was erased or you purchased a new security token, you can always recover S1 by following the same procedure with the offline computer I described above (it is best if you first get Ps1 from the blockchain and provide that to the tool so that it is sure it is using the correct index to generate ps1 and thus S1), assuming you have the encrypted brain-key b and know the master passphrase m.

Also, if you lose the security token, it is probably best practice to replace the secret with a new one (even though it is unlikely for the adversary to be able to obtain it from the device). Or if the light wallet server is compromised (private key l is compromised), S1 is no longer safe to reuse. In either case, it must be possible to update the shared secret that the security token and light wallet server both use. You can get Ps1 from the blockchain (the one you are trying to replace) and take it to the offline computer. The software can then iterate through the indices it uses to generate hardened child keys from ps until it gets ps1 (corresponding to public key Ps1) and then go one index more and generate ps2 and its corresponding public key Ps2. From there is does EC multiplication of ps2 and L to generate S2, which it then stores on the hardware token. Also, the tools on the offline computer would construct a transaction (the flash drive would have to include some information stored by the light wallet that specified a balance controlled by the 2-of-3 multisig from which to pay the fee) to update the account record so that the "one-time security public key" is set to  Ps2, and then it would sign that transaction with pm and pw and save it to the flash drive. The light wallet could then take that signed transaction and send it to the server to broadcast so that the blockchain is updated and the server knows to use the new S2 shared secret to generate one-time passwords.

So the end result of all of this is that you have your light wallet (mobile or desktop app) which stores some important information locally that is encrypted on disk by your wallet passphrase and can be recovered (the importants keys, not the transaction history) using the master key (pm). The master key can be recovered using the encrypted brain-key and the master passphrase. To actually use the light wallet to spend funds, the light wallet server would require you to enter a one-time code that is displayed (and frequently updating) on a separate small hardware device (the security token). Even if the computer storing the light wallet software is compromised, the attacker cannot just steal all of your funds if they do not possess your security token. However, if the light wallet is compromised, then the next time you go to make a transaction that requires the one-time code, the attacker can get the light wallet server to sign a transaction that steals your funds even though from your perspective the transaction was benign. For this reason, the light wallet server will impose spending rate limits. If you will be transferring funds to other accounts/addresses and including this transfer the accumulated value of funds transferred within a moving time window is over some threshold (which the light wallet server could provide ways for you to securely adjust), then the light wallet will refuse to sign your transaction and perhaps allow you to use other methods to authorize the transaction. For example, if you subscribed to a premium light wallet service that required a monthly fee (rather than just a small transaction fee per transaction), it could allow you to authorize a transaction that went over the spending rate limits if they could confirm your intent over a one-on-one phone call.

I understand when you say it's a false sense of security, however, obviously that wouldn't grant the user invulnerability. It would be just a method to prevent some attack methods. Not 100% safe, yeah, I agree with that, but it's still more secure than nothing. And I understand if someone really values his stake, that person will take all safety precautions possible, however I just cannot see the average joe doing all of that. This would be a simple method for the average person to get a higher level of security, even though that doesn't mean his waller is invulnerable so that should be mentioned, but still, as I want to emphasize, for the average joe, it might be a good method to reduce attacks. I appreciate your input and help very much, but someone new who is just interested in trading will be scared just to look at that wall of text. Sure in the future it might be easier, but if it's not, I just can't see the average person doing that. That's why I suggested the mouse hovering thing, due to being something accessible to the masses, average users, unless the method you mentioned can be simplified of course

[arhag]

Not to mention people will feel more secure

Yeah, a false sense of security. As xeroc mentioned, once your machine is compromised, you cannot rely on any of these tricks.

The real solution as usual is: multisig.

The light wallet server can serve double duty as the second signer in a 2-of-3 scheme.

The light wallet server has a public key L and corresponding private key l. Save L to a flash drive that also contains special trusted BitShares tools.

You use an offline trusted computer running a live Linux CD and the BitShares tools on the flash drive to generate a random private key pm (corresponding public key is Pm). Deterministically derive private key pw (corresponding public key is Pw) as hardened child key of pm with index 1 and private key ps as a hardened child key of pm with index 2. Deterministically derive private key ps1 (corresponding public key is Ps1) as hardened child key of ps with index 1. EC multiplication of ps1 and L gives S1. Use your own strong master passphrase m to encrypt pm and represent the encrypted key in brain-key form (passphrase consisting of a sequence of dictionary words) as b. Use your wallet passphrase w to encrypt pw as p. Save b, p,  Pm, and Ps1 to a flash drive (also you can write down b on a paper backup). Plug in a security token to the machine and use the software tools to write S1 into its secure firmware (overwriting any previous secret stored in that location) and also adjust its clock if necessary. Then shut down the offline computer.

Take the flash drive to an online computer with the light wallet (or alternatively to a computer that will let you communicate p, Pm, and Ps1 to your smartphone/tablet via email / cloud / QR code). Let it import p, Pm, and Ps1 from the flash drive (or alternative source) and store it in its local storage. Then it should prompt you for your wallet passphrase w, decrypt p using the w into pw in memory, and then go through the process of letting you register a new account if public key Pw isn't already registered on the blockchain.

You type in the account name you want to use and it tells the light wallet server to generate a new transaction to register that account name to public key Pw on the blockchain, and as a part of its public account record it is specified that it is a public_account, it stores Ps1 as an additional key in the record called the "one-time security public key", and it also specified it wants to receive funds using a 2-of-3 multisig where the three addresses are the ones corresponding to the public keys Pw, Pm, and L. It receives this transaction, signs it using pw, and sends it back to the light wallet server so that the server can also sign it (to pay for its registration fees) and broadcast the transaction.

All funds sent to that account will automatically use that 2-of-3 multisig condition for withdrawal. Those funds could always be spent by the user alone (even if the light wallet server disappears) as long as the user can get access to the encrypted brain-key b (which should be backed up in multiple places including the flash drive, paper backup, and perhaps a cloud service) and knows the master passphrase m. But the usual way those funds will be spent is by signing the transaction with the private key pw that is decrypted in the memory of the light wallet (assuming the wallet passphrase is provided) and by the light wallet server using private key l. For the light wallet server to sign any transaction already signed by pw, it also needs the light wallet to provide a one-time password over their secure connection. This one-time password is deterministically generated from the current time and the shared secret S1 (which the light wallet server can generate using EC multiplication of the known public key Ps1 associated to the account on the blockchain and the server's private key l).

The shared secret S1 is not known to the computer running the light wallet (which is what provides multi-factor security). Instead it should be securely stored inside of the security token. Ideally, the hardware device is designed so that it is difficult to get the secret out of it, but it is theoretically possible to do so if the adversary has physical access to the token. Also, keep in mind that anyone could easily erase the secret if they could get physical access to it even for a short period of time (plus you could lose the device anyway and need to replace it). Whether the secret was erased or you purchased a new security token, you can always recover S1 by following the same procedure with the offline computer I described above (it is best if you first get Ps1 from the blockchain and provide that to the tool so that it is sure it is using the correct index to generate ps1 and thus S1), assuming you have the encrypted brain-key b and know the master passphrase m.

Also, if you lose the security token, it is probably best practice to replace the secret with a new one (even though it is unlikely for the adversary to be able to obtain it from the device). Or if the light wallet server is compromised (private key l is compromised), S1 is no longer safe to reuse. In either case, it must be possible to update the shared secret that the security token and light wallet server both use. You can get Ps1 from the blockchain (the one you are trying to replace) and take it to the offline computer. The software can then iterate through the indices it uses to generate hardened child keys from ps until it gets ps1 (corresponding to public key Ps1) and then go one index more and generate ps2 and its corresponding public key Ps2. From there is does EC multiplication of ps2 and L to generate S2, which it then stores on the hardware token. Also, the tools on the offline computer would construct a transaction (the flash drive would have to include some information stored by the light wallet that specified a balance controlled by the 2-of-3 multisig from which to pay the fee) to update the account record so that the "one-time security public key" is set to  Ps2, and then it would sign that transaction with pm and pw and save it to the flash drive. The light wallet could then take that signed transaction and send it to the server to broadcast so that the blockchain is updated and the server knows to use the new S2 shared secret to generate one-time passwords.

So the end result of all of this is that you have your light wallet (mobile or desktop app) which stores some important information locally that is encrypted on disk by your wallet passphrase and can be recovered (the importants keys, not the transaction history) using the master key (pm). The master key can be recovered using the encrypted brain-key and the master passphrase. To actually use the light wallet to spend funds, the light wallet server would require you to enter a one-time code that is displayed (and frequently updating) on a separate small hardware device (the security token). Even if the computer storing the light wallet software is compromised, the attacker cannot just steal all of your funds if they do not possess your security token. However, if the light wallet is compromised, then the next time you go to make a transaction that requires the one-time code, the attacker can get the light wallet server to sign a transaction that steals your funds even though from your perspective the transaction was benign. For this reason, the light wallet server will impose spending rate limits. If you will be transferring funds to other accounts/addresses and including this transfer the accumulated value of funds transferred within a moving time window is over some threshold (which the light wallet server could provide ways for you to securely adjust), then the light wallet will refuse to sign your transaction and perhaps allow you to use other methods to authorize the transaction. For example, if you subscribed to a premium light wallet service that required a monthly fee (rather than just a small transaction fee per transaction), it could allow you to authorize a transaction that went over the spending rate limits if they could confirm your intent over a one-on-one phone call.

[xeroc]

When I open my wallet I can't see anything without introducing the passphrase. The only thing that shows to me is the box to introduce the pass. Weird.

That's because the GUI does not expose the wallet without passphrase for
convenience reasons.

What about introducing a new way when the user inputs the pass? Banks use a
virtual keyboard to do that. I know that some key-loggers can still get a
screenshot whenever you click but the number of ways to hack someone's pass
would be reduced. Most key-loggers record key strokes. We can prevent that by
introducing a virtual keyboard when the user opens the client or simply an
option to do so. I know operative systems already come with a virtual keyboard
but still, if we do that, maybe more people will use it and we can prevent more
hacks. Not to mention people will feel more secure

So we have a virtual keyboard. Still, hackers can get a screenshot each time you
click so maybe we can get a system where you only need to hover your mouse over
a key on the virtual keyboard, and it automatically assumes that as an input
after 2 seconds for example. You just let the mouse cursor over a key and that's
it! I came up with this after remembering how banks operate and researching a
little. Would this be something that could be implemented? I don't have the
skills but we could make an announcement saying we're looking for a delegate to
develop that if it is a good idea

In the end, even if all these methods are exploitable, at least we've managed to
reduce possible attack vectors so it's still a win for us. I can't recall any
other project with a system like that so it would benefit us being the only ones
with a better log in security

When in comes to crypto currencies, physical security is essential. Hence,
BitShares and all other CCs cannot be run securely on hardware you don't trust.

[Akado]

A "read-only" is absolutely possible just not "easy-to-do" with the current GUI. If you were to just open the wallet in the cli you can see everything but can't spend without passphrase.
The passphrase only encrypts the private keys. pretty much the same as in bitcoin

When I open my wallet I can't see anything without introducing the passphrase. The only thing that shows to me is the box to introduce the pass. Weird.

What about introducing a new way when the user inputs the pass? Banks use a virtual keyboard to do that. I know that some key-loggers can still get a screenshot whenever you click but the number of ways to hack someone's pass would be reduced. Most key-loggers record key strokes. We can prevent that by introducing a virtual keyboard when the user opens the client or simply an option to do so. I know operative systems already come with a virtual keyboard but still, if we do that, maybe more people will use it and we can prevent more hacks. Not to mention people will feel more secure

So we have a virtual keyboard. Still, hackers can get a screenshot each time you click so maybe we can get a system where you only need to hover your mouse over a key on the virtual keyboard, and it automatically assumes that as an input after 2 seconds for example. You just let the mouse cursor over a key and that's it! I came up with this after remembering how banks operate and researching a little. Would this be something that could be implemented? I don't have the skills but we could make an announcement saying we're looking for a delegate to develop that if it is a good idea

In the end, even if all these methods are exploitable, at least we've managed to reduce possible attack vectors so it's still a win for us. I can't recall any other project with a system like that so it would benefit us being the only ones with a better log in security

[xeroc]

A "read-only" is absolutely possible just not "easy-to-do" with the current GUI. If you were to just open the wallet in the cli you can see everything but can't spend without passphrase.
The passphrase only encrypts the private keys. pretty much the same as in bitcoin

[Akado]

Would it be possible to access the wallet without the need for the full password? The user would only use a 4 or 5 (or custom) number of digits. This however, would only unlock some parts of it, for example, to see if it's synced and to check transactions. Transaction details such as the amount of bts sent or received could be omitted and could just show if the user received or sent.

This way the user could easily monitor his account to check if everything is in order with an easier to remember code and without the need to expose his password. Then the password would be used to get more permissions such as doing transactions.

This could even be customizable to allow the user to see his balance or not with the PIN only, allow backups or not, etc. Transactions and voting would still need the password to be done.

What do you think? I know this might not be a priority right now but could improve user experience with the wallet.