BSIP: Proposals Scam Prevention

[litepresence]

BSIP: NOT YET ASSIGNED
Title: Proposals Scam Prevention
Authors: litepresence finitestate@tutamail.com
Status: [ Draft ]
Type: [ Protocol ]
Created: 2019-03-10
Discussion: NO URL
Replaces: Core Issue 1644
Superseded-By: None
Worker: None

Abstract

There are rampant scam proposals being sent to lay users posing as official sources with fake official looking names to "upgrade accounts" or "improve security". The user believes the correct thing to do is accept the proposal. Shortly thereafter they realize they've agree to give all their funds away.

Motivation

It is poor business practice to create tools which are prone to be used by hackers to steal user funds.

Competency and Free Contract are legal requirements for a valid contract.
There cannot be free contract when there is misrepresentation.
There cannot be competency when all detail of contract are not disclosed.

Where there are on blockchain invalid contracts there will be legal consequences in brick and mortar courts.

Further, whenever there are invalid contracts, the standard choke points for exit from crypto markets will be burdened with the blacklisting of scammer funds. This includes Gateways, Centralized Exchange Operators, and Faucet Providers. All of which are ultimately staffed by developers who will be redirecting development time to chasing down ghosts of scammed accounts.

It is my hope that this BSIP and resultant discusssion will be a focal point for suggesting and validating technical solutions to the proposal scam issue until every vector of such attack has been shut down and stamped out.

Rational

Without a technical solution in place this scam will continue to tarnish the reputation of BitShares. The day after the user, which prompted this bsip lost funds, another user reached out to me with a scam proposal. It is all to common and the results for those taken are beyond devastating.

Discussion

I think we've all seen it coming. Here it is.

$80,000.00 Gone

Richard Hanna, [09.03.19 22:25]
OMG i had no idea wha tthat was all about 
i thought it was a security enhancement... 
what can i do? i want to kill my self

Proposals lacks a metric of trustworthiness, this needs a technical solution. I don't know what it is, but this outcome was predictable as a consequence of the code base in light of human nature, yet unacceptable from both moral or business perspective.

This needs to stop.

This is a gaping hole in the legitimacy of the platform; we cannot have new users randomly getting scammed for large sums of money. The subject needs to be fleshed out as to what is and is not possible from technical perspective to mitigate this risk.

via telegram "BitShares Community" group (https://t.me/bitshares_community)

Richard Hanna, [09.03.19 22:08]
anyone- asking for your help... 
maybe wrong forum but my bitshares account got hacked 
and someone stole 2,000,000 BTS... im devastated...
the thief account name is:  joouwoo3c...what can i do?

Krista, [09.03.19 22:20]
It looks like the newest part of a scam to update account data ....
did you click on a proposal?

Richard Hanna, [09.03.19 22:22]
im not sure, i may have, i only check in every couple months... 
how would i know?

Krista, [09.03.19 22:22]
What is your bitshares account name?

Richard Hanna, [09.03.19 22:22]
rwh-9164

Krista, [09.03.19 22:24]
See this ?? [ Photo ] They proposed and you accepted

Richard Hanna, [09.03.19 22:25]
OMG i had no idea wha tthat was all about 
i thought it was a security enhancement... 
what can i do? i want to kill my self

Krista, [09.03.19 22:26]
Oh no, don't do that *hugs* 
that is exactly what they wanted you to do 
was to think it was legitimate

Krista, [09.03.19 22:26]
There are a ton of accounts that run this scam

Potential Specifications

HIGH FEE FOR REJECTED PROPOSALS

If accept and reject proposal fee could be separated; not sure of technical end of this... but in theory you could set reject fee high and imposed on the initiator of the proposal. Perhaps as high as $10 equivalent such that nobody proposes anything without knowing in advance that the other party intends to accept. That is, negotiate first, agree, then propose, and finally accept. Or take risk that you will be charged $10 for failure to first disclose your intentions openly. As it is not possible to be charged a fee unless you give permission, the proposer should be charged the $10 fee ALWAYS and then REFUNDED if the proposal is accepted via a vesting balance.

FREE PROPOSAL REJECTION

There is currently a fee associated with rejecting a proposal. This fee should be set to ZERO. A user should not have to PAY to make a "accept scam" button to go away.

DUE CONSIDERATION ACCOUNT UPGRADE

By default a new account cannot receive proposals at all without explicitly "upgrading" the account and signing some contract that makes clear the type of scams proposals are prone to. I would be in favor of having to PAY to upgrade to receive proposals as a matter of contractual "due consideration".

WHITELIST

Bhuz, [10.03.19 13:58] What about adding a whitelist for proposals? How hard would it be and how would that impact legit business? I think just having a whitelist on proposals make both sense and potentially solves the majority of scams without really affecting legit business that may want to use proposals. For whitelist on proposals I mean a user defined list that contains account names that are allowed to create proposals for the account in question. Cons I see is more RAM needed for consensus witness node, probably need to set an hard limit on the list length

Christopher Sanborn, [10.03.19 15:40] I like this idea. Vast majority of users don't need or expect others to propose transactions on their behalf. Those that do, could/should take steps to enable it.

NAME REGULATION

The majority of these scams seem to arise from users that are either using an account name that sounds like a legitimate business or initiating a proposal with the word "security" in it as a method of deceit. A potential solution is to regulate any account name with "BitShares", "security", "open-ledger", "rudex" and disallow accounts with specific words in them from proposing transactions.

In most countries the word "bank" cannot be used by anyone except a state approved bank. eg Australia: "APRA limits use of ‘bank’, ‘banker’, ‘banking’ and ‘ADI’, and by extension words or expressions with like meanings (such as ‘banque’)."

Bhuz, [10.03.19 14:38] It's hard to define what names need to be "regulated", it's hard to defend from similar/misspelled names, it's hard to update such a global list

DELAY TRANSFER WITH OPTION TO REVERSE

What about any funds that transfer via proposal move to some type of "vesting" balance and are non accessible for some period and there is option for reversal/refund within 24 hours? Is this possible?

P2P SOCIAL CREDIT SCORE

Is it possible to know percent of proposals accepted/denied by this user?

Would it be possible to have some form of rating system like you do at ebay where post transaction you rate the other party?

UI LEVEL FILTRATION

Stefan, [09.03.19 23:55] The recent UI update 190227 needs double checking to see the approve button, with a warning hint.

One first step could be to allow the UI to use an on chain whitelist on top of hard-coded scam account names to allow swift react

MAKE EXPLICIT THE NATURE OF THE CONTRACT

There is no attempt currently made by the bitshares-UI to parse the nature of the proposal. Until such time as the proposals are 1) TRANSLATED from Graphene into English 2) DISPLAYED to the user, then under no circumstance should a button be presented to the lay user to ACCEPT terms of a contract both presented in obscure foreign language and without any apparent link to greater detail.

BASIC AND ADVANCED UI VERSIONING

h/t @murda_ra There could be two versions of the reference UI: 1) standard / basic - which DOES NOT include proposal abilities 2) advanced version - which includes all features and includes a disclaimer upon download

RELATED ISSUES

differentiate between scam and unkown proposals https://github.com/bitshares/bitshares-ui/pull/2429

Show required fee amount on permanently-reject-proposal page https://github.com/bitshares/bitshares-ui/issues/2527

Clearly render proposal contents https://github.com/bitshares/bitshares-ui/issues/2499

Increased user failsafe and security https://github.com/bitshares/bitshares-ui/issues/2460

Whitelist tab enhancement https://github.com/bitshares/bitshares-ui/issues/2423

Handle proposals related to phishing accounts https://github.com/bitshares/bitshares-ui/pull/2178

Document how proposals work https://github.com/bitshares/bitshares-core/issues/731

UI Scam Alert https://github.com/bitshares/bitshares-ui/issues/2529

KNOWN BLACKLISTED ACCOUNTS

https://github.com/bitshares/bitshares-ui/blob/develop/app/lib/common/scamAccounts.js

EXAMPLE SCAM PROPOSALS https://open-explorer.io/#/objects/1.10.24449

Screen Capture of $80,000 loss

Summary for Shareholders

1) The proposal mechanism can be used to defraud unexpecting users through misrepresentation. 2) Contractual misrepresentation is a criminal act of theft in virtually all jurisdictions 3) The User Interface is being exploited to hide the true nature of scam proposals. 4) There are a multitude of potential solutions to the issue, each of which needs to be thoughtfully considered.

Copyright

WTFPL

[christophersanborn]

The whitelist idea is a great idea imho.

[CryptoKong]

Absolutly agree. accounts should have to be whitelisted in order for a proposal to be created. This should also apply to the barter feature. There is no good reason to propose a transaction or barter with someone you have not communicated with beforehand.

[grctest]

Perhaps a couple extra steps warning users in the UI when looking at a proposal which affects keys? A couple extra prompts to remind people that giving away their account is a bad idea you would hope would be sufficient to prevent the user from falling for such a scam?

I don't agree with a centralized whitelist over who can create proposals, and I'm hesitant to support locking down proposals to only mutually whitelisted individuals because that could be a major barrier to bartering.

[xeroc]

I would kindly request to use the template provided in the root directory of this repo when submitting new BSIPs.

[litepresence]

@xeroc updated per template, hopefully is acceptable. I was hot under collar when I posted... burns to see people get taken. I got into this BitShares scene because I was fed up with directing people to centralized exchanges only to see them later complain of hacks and exploits.

screen caps from another scam proposal sent to a user this morning

the user has to click: PERMANENTLY REJECT then a second window pops up where the user must PAY A FEE (mind you less than half a penny in value) and click again on: PERMANENTLY REJECT just to make the scam go away; else wait 24 hours for it to expire.

THE ACTUAL GRAPHENE OF SUCH AS SCAM LOOKS LIKE THIS

https://open-explorer.io/#/objects/1.10.24449

With the untranslated detail there is little way for a lay user to understand the nature of the proposal presented. Without a sizable background in both cryptocurrency and dex technology, nor is there a strong understanding as to whether to immediately approve or reject such an offer. "What should I do?"

[abitmore]

I created https://github.com/bitshares/bitshares-ui/issues/2527 in bitshares-ui repository for the proposal rejection fee issue.

[pmconrad]

IMO crippling functionality is not the right solution when dealing with user stupidity. (General rule: when you think you've made your software foolproof, evolution kicks in and creates bigger, better and faster fools.)

The idea about having the proposer pay a high fee is bad because it breaks with one important thing: anyone who has to pay for an operation must approve the transaction. It also opens up ways to cause damage to users and businesses by deliberately rejecting legitimate proposals.

Account upgrade may be a viable solution, although that might be seen as a rip-off by some.

Whitelist can be implemented client-side.

Regulation on account names might be perceived as a proof of centralization. I think we don't want that.

Delayed transfer is useless because there are many ways to empty an account for a profit, for example by trading funds away for a worthless UIA. Also note that the root of the problem is that the users is giving control over his account away, so he will not be able to reverse transactions anyway.

Rating system can be implemented client-side. Also, ratings systems / social score are never secure against abuse.

[bangzi1001]

Bitshares UI: Add Scam Alert https://github.com/bitshares/bitshares-ui/issues/2529

[litepresence]

2527 and 2529 both added to op

[litepresence]

https://bitsharestalk.org/index.php?topic=27856.0

Dear Forum members,

I would like to report my account hijack that happened around Feb 7th. As I did not check my account frequently, I just found out that my balance became almost 0 when I checked on Feb 15th.

I lost almost all cryptos that I owned and I would like to inform all Bitshares holders of this incident so that no more victims will be created.

I checked some google and found out that there was malicious Bitshares proposal around end of January in 2019. I believe my account was hijacked by this malicious proposal and he/she stole all crypto. I do not think I approved this proposal but I might have accidentally approved.

I have just attached cryptofresh https://cryptofresh.com/u/tsuratsura-3557 and this is the all I have. I do hope Bitshares will prevent this kind of malicious proposal from attacking all members in the future.

Should you require anything further, please let me know.

Regards,

Toshi

also reply:

postup5 Newbie

I did hear back after a few days regarding my ticket. Seems there is nothing they can do. Here is a link to my bitshares explorer account page:http://bts.ai/u/postup5 Looks like openledger-security has control and has all but drained it. It is unacceptable that nothing has been said or done to protect others from this exploit. I won't be using bitshares anymore.

[litepresence]

Blog posts here describing this issue:

https://steemit.com/community/@erodedthoughts/bitshares-scam-proposed-permission-update

https://steemit.com/bitshares/@krazykrista/bitshares-scam-do-not-accept-proposed-transactions-that-update-your-account-data

https://steemit.com/community/@erodedthoughts/bitshares-scam-proposed-permission-update

https://steemit.com/bitshares/@kingscrown/watch-out-the-bitshares-scam-going-and-getting-more-sophisitacted

[litepresence]

IMO crippling functionality is not the right solution

If it was functional there would not be users routinely getting scammed. It is inherently dis-functional as it stands in the "reference" user interface: there is a button to accept a proposal who's details are not disclosed nor translated into plain language. It is all to easy for malevolent actors to spoof a malicious proposal to appear to be important and from an official source. This is not functional software, it is liability and disgrace in the making. It does not matter how many warnings or steps you put between accept and deny. Until there is a plain English contract it should not be exposed to lay users.

The idea about having the proposer pay a high fee is bad because it breaks with one important thing: anyone who has to pay for an operation must approve the transaction.

This issue is easily solved by requiring the proposer to pay the fee in advance and get a refund upon acceptance via vesting balance.

It also opens up ways to cause damage to users and businesses by deliberately rejecting legitimate proposals.

Shoving contracts in people's faces who have no interest in such contracts is harassment. There is nothing legitimate about contracts that have not been negotiated and agreed to in advance between parties. The proposal system as it stands creates an open door to misrepresentation and incompetency; leaving the contracts legally invalid. If any of these scams saw the light of day in court invariably those behind the exploits would see criminal and civil penalties.

[pmconrad]

Of course the software is functional. If users don't read and mindlessly click on "OK" three times(!) even if they don't understand what they are doing you can hardly blame the software.

On-chain contracts will never be "plain English" (and if they were they'd still be invalid in most countries).

There is nothing legitimate about contracts that have not been negotiated and agreed to in advance between parties.

How can you ever enter a contract if you demand that it's been negotiated and agreed upon before it is even presented? The chain cannot tell if you have an out-of-band agreement with the proposer. Proposals are the technical means to reach such agreements.

Btw, I regularly receive invoice addressed to my business, for "registration in the world online catalog" and stuff like that. Needless to say, I never did register. The trick is that by paying the invoice I agree to the contract. Perfectly legal, and still I call this a scam. And SPAM too.

[litepresence]

[litepresence]

How can you ever enter a contract if you demand that it's been negotiated and agreed upon before it is even presented?

Presenting only the signature line of inherently obfuscated content is not presenting "a contract". A legal contract has certain elements which have evolved over time in common law. If we are to call things contracts on blockchain... then they should mirror these required elements as established through time. Namely, mutuality of agreement...

[litepresence]

The latest version of this exploit now requires THE SCAM PROPOSER's authority to reject the proposal. The user has NO ABILITY to even pay to make the proposal go away; his only option is to wait for it to expire.

[abitmore]

@litepresence I don't think it's the case. required_approvals->find() != end() means the account you tried to pay fee to reject the proposal is not in the list. However, your account need to be in the list to be able to approve it. So I think you've tried to pay with another account. Maybe there is a bug in UI that may cause you to choose to pay with another account?

[pmconrad]

1. We don't call it contract, we call it proposal.
2. "Inherently obfuscated" is debatable. All that's necessary to know is there. I wouldn't call it more obfuscated than a 10-page "Terms of use" document on a CEX, for example.
3. Acceptance of a proposal (as well as physically signing a contract) implies understanding. If you don't understand then don't sign, and don't click on "OK".

[abitmore]

I posted an idea here: https://github.com/bitshares/bitshares-ui/issues/2658#issuecomment-489321182