Author Topic: If account names are not transferable, what happens when wallet is compromised?  (Read 5001 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
I think your post hrlps my point. It took 3 paragraphs to explain how the user experience rules and parts rely on having a working reputation system. You should see how many user errors we see just with the cases we have now (local/unregistered/out-of-sync working together in different ways).

The detail in my explanation is to explain to client designers what the problems are and how the GUI can be designed to avoid them. Regular users don't need to care about these details. If the GUI is well designed, I think the experience can be very intuitive, and in the corner cases the client can catch the potential errors and give users a clear explanation of what needs to be done.

The short explanation to users is the following:
Quote
Never send anything to a user that is not on your contact list.
If you want to add someone to your contact list you have three options:
  • Add them by clicking on the add link from a trusted website.
  • Trade your virtual "business cards" using your mobile client. For extra security, after the exchange happens confirm you both have the same random confirmation phrase before pressing the add button.
  • If you absolutely have to search for and add someone using their unique handle, be REALLY REALLY sure you spelled the name correctly AND check that the name registration date clearly displayed on your client is BEFORE the date they gave you the handle.

I suppose I'm also thinking more about keyid than about btsx names, maybe they need different behaviors

Can we eventually just get rid of BTSX names (and names on every other DAC other than the ones explicitly meant to be namespace DACs, i.e. KeyID names)? I think they are more trouble than they are worth. Ideally, there would be a easy mechanism for a DAC client to make a request to the DNS DAC whenever it wants to add a new user to the contact list via their unique KeyID handle. Also, it is probably a good thing to not see account names of delegates not in your contacts whenever voting. It forces people to verify the identity behind the delegate active key by adding them to their contact lists rather than just assuming it is the same trustworthy person they know from the forums just because they share the same name as their forum handle.


Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I think your post hrlps my point. It took 3 paragraphs to explain how the user experience rules and parts rely on having a working reputation system. You should see how many user errors we see just with the cases we have now (local/unregistered/out-of-sync working together in different ways).

I suppose I'm also thinking more about keyid than about btsx names, maybe they need different behaviors

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
My perspective is that we are trying to never show keys and make it "intuitive" with only names while at the same time treating keys as "higher-class" citizens than names. This schema breaks in worse ways than "I don't get to have my  name" when you let people transfer. Scamming becomes easier, making mistakes becomes easier. Fixing it requires a reputation scheme (none I've heard so far are satisfying) or top-down intervention.

I don't think these scamming/spoofing/accident issues are anything a decent GUI design that enforces best practices can't solve. There should be BIG HUGE WARNING FLAGS and annoying confirmation requests anytime you want to send anything valuable to a named account that is not in your contacts list (favorites). Also, in my view the local alias for accounts should take precedence over their global name (and local aliases in your contacts list should autocomplete in the to field of transfers while global ones should not). Let me explain with an example. If I add your account ("nikolai") to my contacts list, it should create a local account with the local alias "nikolai" (and of course it knows the global name is "nikolai" as well). I should then be able to change the local alias to "toast" even though that conflicts with the global name "toast" that is registered by someone else. If I send money to "toast", my client should send the money to you without complaining. Prior to doing this renaming, if I tried to send money to "toast", the client should complain that the BTSX user named "toast" is not in my contacts list and require that I first add the account to my contacts, or if I am really sure I can press these series of tiny obscure links/buttons to have it go through anyway. This warning would hopefully remind me: oh shoot, "toast" on BTSX is not really toast, I meant to type "nikolai", let me cancel this and fix the problem. I would then add "nikolai" to my contacts, maybe give it the alias "toast" for my convenience, and no longer deal with that silly problem again. It would be even better when we have web-of-trust reputation systems, because if I go to add "toast" accidently, I would notice the surprisingly low reputation score for someone who I know should be well respected in the community, which would then hopefully jog my memory or incentivize me to do further research to discover the reason behind it.

So why bother having these global TITAN names in the first place when we could have just done it with local aliases and active public keys? Honestly, in some ways that might have been the better way to go to avoid so many mistakes people make. However, there is still some value in being able to communicate a free human-memorizable name to other people in a non-digital setting. If I had an encounter in person with someone I just met, and as I had to go they said they wanted to send me a tip, or send me a message on KeyMail, or whatever, and they wanted to know my unambiguous handle to reach me, I could just say "I'm arhag on BitShares X, that's A, R, H, A, G." Being able to do that is useful, so I think there is still value in global TITAN names. What happens if I realize my account was compromised before this person contacts me or sends me money? I revoke my account, then when the person goes to add me to their contacts, their client warns them that this account was recently revoked when they try to add me. What if I revoke after they add me to the contacts? Well, their client will warn them that the account in their contacts was revoked and temporarily disable sending anything of value to that account until the user deals with the issue. The user would have to manually confirm the new global name that I associated with that account (and possible change the local alias if the user desired) or just re-enable the account with their preferred local alias even if I didn't associate a new global name to the account.

Finally, even if people were allowed to rename their global TITAN name to a revoked name, there still shouldn't be many issues in a well designed client. Let's say I really wanted the name "a" but it was taken. But then recently, after telling some new person I met that my BTSX name was "arhag", I discover the "a" name was recently revoked or maybe it expired somehow. I decide to switch my name to "a". Now everyone who had me in their contact list will get the update next time they use the client that "arhag" changed his name to "a". They will confirm this change in the client and decide whether they want to change their local alias for me or not. The new person I met has knowledge that my name was "arhag" still but has not yet put it into their client. Before this new person was able to do that, someone else took the "arhag" name for themselves. Now when the new person I met goes to add "arhag" to their contacts list, they would be adding the other guy and not me, BUT the client can warn the user that this name changed ownership recently. By comparing the time the change happened to the time the person remembers me telling the person that my name was "arhag" this person will know that it is no longer safe to assume this "arhag" is the same person they met. But the blockchain has enough information there to tell that user that the "arhag" that existed at the time I told them my name was "arhag" is now renamed to "a". Problem solved.


Offline blahblah7up

  • Full Member
  • ***
  • Posts: 192
    • View Profile
if pushing transactions to the network became possible like in this scheme: https://blockchain.info/pushtx

it would then be possible to have a cold storage account where the owner key never touches the internet and you could fund any hot account you create from it.

Offline bytemaster

Account Owners are not transferable, account active keys are.

So you can create an account in "cold storage" and then update the "active public key" any time you think your old "active public key" was compromised.   This is kind of like transferring only it is always controlled by the non-transferable owner key.   

This means that you are safe as long as your "owner key" never sees the internet. 

Creating the tools to "make this easy" is a HUGE effort.
however ... to do this you need the owner key ... thats why you should keep you main name offline .. and only use the subaccount ..

disclaimer: I am not doing so .. yet ... ;-)

I am not talking sub accounts... individual accounts have "owner" and "active" keys which are different.    Sub accounts does accomplish a similar thing though.... but you probably don't want a bunch of "dead" sub accounts hanging around.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Account Owners are not transferable, account active keys are.

So you can create an account in "cold storage" and then update the "active public key" any time you think your old "active public key" was compromised.   This is kind of like transferring only it is always controlled by the non-transferable owner key.   

This means that you are safe as long as your "owner key" never sees the internet. 

Creating the tools to "make this easy" is a HUGE effort.
however ... to do this you need the owner key ... thats why you should keep you main name offline .. and only use the subaccount ..

disclaimer: I am not doing so .. yet ... ;-)

Offline bytemaster

Account Owners are not transferable, account active keys are.

So you can create an account in "cold storage" and then update the "active public key" any time you think your old "active public key" was compromised.   This is kind of like transferring only it is always controlled by the non-transferable owner key.   

This means that you are safe as long as your "owner key" never sees the internet. 

Creating the tools to "make this easy" is a HUGE effort. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
My perspective is that we are trying to never show keys and make it "intuitive" with only names while at the same time treating keys as "higher-class" citizens than names. This schema breaks in worse ways than "I don't get to have my  name" when you let people transfer. Scamming becomes easier, making mistakes becomes easier. Fixing it requires a reputation scheme (none I've heard so far are satisfying) or top-down intervention.

For names that are transferrable (domain names), the UI for names handles the fact that they might have changed owners more naturally, but requires you to hide a lot of functionality related to the key to prevent people from doing dumb or dangerous things.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
If BM and the dev team really don't want account transferring, perhaps they could implement an 'account burn' feature, which allows you to permanently disable an account from sending/receiving/transacting. Any person attempting to send this account funds would get their funds sent back, with the memo that the account burner used in their burn transaction.

On second thought, maybe the memo feature would be too useful to an account hacker, eg "btercom has a new address, please send funds to xxblademasterxx for all future deposits instead."

When you revoke an account it would make everyone else's wallet be super paranoid about that account. That is better than being able to transfer which makes compromises deadly.

In your example, the memo field could be crossed out in red with a tooltip "this account is revoked - do not trust any interactions with this account", and disable transferring at the wallet level.

That's smart.

Although it screws me.  I registered my favorite names on a computer I don't fully trust (basically any internet connected computer).  Now I can never really trust them.  If I could transfer them to my cold storage wallet they would be rehabilitated.

Obviously revocation like you described is necessary for when you know you've compromised.

An alternative to revocation only, would be to allow transfers, but make them official only after a week (or the equivalent number of blocks) passes without revocation from the old key.  That would ensure that people have time to revoke compromised addresses, but also provide the flexibility to upgrade your security.

As an example, I encrypt all my backups, but sometimes encryption schemes are deprecated (e.g. truecrypt, and many others with NSA revelations).  Now all my backups, some of which have traveled over the internet are potential leaks of my wallet.  I know that TODAY I have exclusive control over my wallet (because no one has emptied it), but I don't want to depend on that forever.  So I want to renew and upgrade my security by transfer to a fresh wallet.  With my BTC wallets, I went through a number of increasingly paranoid wallet transfers as the price went up.

It's sad that I'll have to leave my account names behind in order to be responsible about wallet security.

I understand the concerns about squatting, but the fact is that most of the names worth squatting are already taken anyway!  Giving people who want those names the ability to buy them increases their freedom of exchange.  It doesn't protect people from squatters to prevent people from having any way to get the name that they want.  Free market and all that...

Offline bitcoinerS

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
If BM and the dev team really don't want account transferring, perhaps they could implement an 'account burn' feature, which allows you to permanently disable an account from sending/receiving/transacting. Any person attempting to send this account funds would get their funds sent back, with the memo that the account burner used in their burn transaction.

On second thought, maybe the memo feature would be too useful to an account hacker, eg "btercom has a new address, please send funds to xxblademasterxx for all future deposits instead."

When you revoke an account it would make everyone else's wallet be super paranoid about that account. That is better than being able to transfer which makes compromises deadly.

In your example, the memo field could be crossed out in red with a tooltip "this account is revoked - do not trust any interactions with this account", and disable transferring at the wallet level.

Instead of telling all to be afraid of some account or disabling transfers to it, it would be better to indicate that an account has recently been "registered/transferred/has new owner"
If an account has registration date less than 1 (month, or year) it can be made visually stand out as new. That is enough to let people know to be careful with an account.  Account names should be cancel-able/transferable, and as I already mentioned previously, this is a serious design limitation that will have to be removed sooner or later.
>>> approve bitcoiners

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
If BM and the dev team really don't want account transferring, perhaps they could implement an 'account burn' feature, which allows you to permanently disable an account from sending/receiving/transacting. Any person attempting to send this account funds would get their funds sent back, with the memo that the account burner used in their burn transaction.

On second thought, maybe the memo feature would be too useful to an account hacker, eg "btercom has a new address, please send funds to xxblademasterxx for all future deposits instead."

When you revoke an account it would make everyone else's wallet be super paranoid about that account. That is better than being able to transfer which makes compromises deadly.

In your example, the memo field could be crossed out in red with a tooltip "this account is revoked - do not trust any interactions with this account", and disable transferring at the wallet level.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Sub accounts?  Where do I learn about those?  Can I create those already in the client?
If you own "bar" you can create AND register ie "foo.bar"

Interesting.  And no one else can register foo.whatever?

And I can spend from foo.bar on my hot wallet, even while the keys that secure it the name are only stored on my cold wallet?

How does that work?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Sub accounts?  Where do I learn about those?  Can I create those already in the client?
If you own "bar" you can create AND register ie "foo.bar"

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
agreed.

however there are also physical keyloggers .. that do have access to your keyboard only

Offline fussyhands

  • Full Member
  • ***
  • Posts: 109
    • View Profile
So that means any compromise, or suspected compromise of my wallet results in loss of my account names forever?

Isn't that a problem, if people out in the world still have my account name and are sending money to it?

Should I only use account names on cold storage?
you should:

have one major account name ie "foobar" (in coldstorage !!! )

you only work with subaccounts .. ie. main.foobar .. home.foobar .. wife.foobar ..
lost keys there can be "updated" (in some sense)

Sub accounts?  Where do I learn about those?  Can I create those already in the client?

That seems like perhaps the best that can be done.  Cold storage for the main account and then sub accounts which cannot be stollen without access to the main account for hot storage.