Tools to prevent man-in-the-middle-attack

[AndreKoster]

This is perhaps out of scope (at least, technically), but important for the future success of bitsquare: How can a seller of BTC pre-empt man-in-the-middle-attacks?

With a MITM attack the buyer of the BTC is not the same person as the actual sender of the money. However, the sender knows the name and bank account of the seller. The sender is usually scammed by the buyer into sending money to the seller. Often, the sender realizes later he is scammed, and assumes the seller is part of the scam. This may lead to the sellers' bank account being blocked and a police investigation. Hence, seller need ways to be able to pre-empt such attacks.

The seller needs to be able to assess if the buyer is the same person as the sender of the money. For this, offer terms should be shown to a candidate buyer before the trade starts. And there needs to be a way for the seller to communicate with the buyer about the fulfilment of the offer terms.

A possible solution would be adding a free text to an offer (to display offer terms) and chat functionality. Both the offer terms and the chat history can then be used by the arbiter in case of dispute.

[ManfredKarrer]

All communication between traders is end to end encrypted, signed and routed over Tor (hidden services), so getting on top of the application side security also Tors security and location privacy. The data for receiving the Fiat (bank account) and all the other trade data (btc address, amount, price,...) are also put into a JSON contract which get hashed and added to the MultiSif deposit transaction (using OP_RETURN). So the moment of depositing into the MS is timestamping the contract.
I cannot see any possibility how to MITM attack that process.

If you would add an interactive step before a take offer request gets accepted, the trade would slow down a lot when both users are not online and I don't see a reason why it should be needed (as I think that MITM is not possible).
There are terms for both traders which get accepted by either publishing the offer or taking the offer they confirm to agree on that terms. All the trade details are visible at that moment and get signed with the deposit tx.

Enabling communication possibilities has more risks and drawbacks then benefits IMO.
It would enable that scammers try with social engineering that they can trick the other peer.
Spam might become an issue.
And finally any free text fields might lead to a market place (adding non-currency goods or services to the exchange) which might be interesting some day but it would require different tools to ensure a safe trade (like reputation).

Regarding fraud with stolen bank acoounts: Yes that is a risk which is mitigated primarily by the low trade limits with payment methods where chargeback is possible (banks). If it turns out that this is not enough we will add a lock time to the payout tx so the arbitrator has longer a possibility to step in if chargeback happen.

[AndreKoster]

I was only referring to social MITM attacks, where the buyer (i.e. the man-in-the-middle) manipulates the the victim into sending money to the seller. I am an active trader dealing with SEPA transfers since nine months, and this issue is a problem. I'm afraid that if bitsquare will be less equipped than (centralized) competitors, the scammers will flock to bitsquare as soon as it catches on. Ultimately rendering the platform unusable for sellers (buyers are not affected).

Longer lock times are not effective in this case, since senders can't easily contact buyers to prevent the release of BTC (they only know buyer's bank account, name, and country).

[ManfredKarrer]

Can you explain such an attack more specifically? How does such a social MITM attack work in praxis?
Do you think with a trade limit of 1 BTC it is still attractive for scammers? At the moment we have 0.5 BTC for bank transfers.
Does the scammer in such a scenario has the name, bank account and trade ID (used in reference text in bank tx) when he starts the trade (take offer)?
If not then the seller should not confirm the receipt (at the moment only the reference text is displayed to him, but the other bank account data could be displayed as well - would be probably good to add).
Lock time of for instance 1 week would give enough time for the victim to discover the fraud and then require a charge back. The seller can report that to the arbitrator and then get his btc paid back and the scammer does not receive anything.
I am aware of the problems when a chargeback happens but that very low success chance should reduce inventives for scammers to even try it out.
OKPay keeps deposited money for 1 week frozen until you can spend it. I assume that is a value from their experience with fraud. And as they say that they don't do chargeback they would need to cover any loss if they get scammed.

[AndreKoster]

Sure. One of the more popular ones is calling people at random, saying they are from Microsoft, and making them believe they have a virus on their PC that urgently needs to be fixed. They guide the victim behind their PC, convinces them of the threat, and end up taking over the PC remotely. After having rendered the service of so-called fixing the PC, their service has to be paid for. Typical amounts are €150 or €200. In the meanwhile, another member of the team searches for buying the corresponding amount of BTC at LocalBitcoins.com or Paxful.com (and in the future, bitsquare). Once a seller is found, they make sure the victim will transfer money by bank to the BTC seller. On demand, they will provide ID of the victim, and/or a screenshot of the transaction being made (from a screen on the remote computer), etc. This makes it hard for the seller to distinguish that the sender of the money is not the same person as the buyer he is dealing with. It can be done, but it requires social interaction with the buyer and knowledge about how they operate.

Part of the victims will file a police report and contact their bank. Their bank contacts my bank, who takes action. Over the past half year, I had my bank account blocked once. Also, I have been summoned by the police for questioning.

Of course, the seller can prove he didn't know what was going on. However, to keep up plausible deniability it requires the seller to take measures to prevent selling to unknown buyers. And this is where I see a risk for bitsquare. If bitsquare becomes a popular marketplace for buying BTC anonymously (at least, anonymously until the deal is done), it will quickly become the preferred marketplace of the scammers in question. This will drive out the sellers who don't want to function as money mules for them. Although I do think that plausible deniability is defensible in court, if this happens often enough a seller will run out of banks for bank accounts -- because banks will close accounts of those who act as money mules once several people complain about being scammed.

Hence, if bitsquare doesn't allow social interaction to be used to determine if buyers are legitimate, I am afraid it will fail as the anonymity of the scammers is protected, while that of the seller is not.

The best solution to this problem should be found in making sure the sender of the money is aware what he is buying (i.e. BTC). I think that's the real challenge.

More info about this type of scams:
http://www.theguardian.com/world/2010/jul/18/phone-scam-india-call-centres
http://www.theguardian.com/technology/blog/2011/mar/01/microsoft-virus-scam-continues

[ManfredKarrer]

Thanks a lot for that info.

One solution could be to use optional bank account verification:
Verify the bank account by doing a small tx of e.g. 0.1 EUR to an arbitrator who pays it back after he received it. That arbitrator provides then a signed "certificate" that this bank account is connected to a specific Bitsquare network ID (onion address).
With that the scammer would need to convince the victim to send first that verification amount to an arbitrators bank account before being able to use that account for scams. I think that step would add sufficient friction/delay for the scammer to succeed.

Which bank transfer types are usually used for those scams? SEPA?
Are there counties where the scams are happening more frequently? In Bitsquare you can limit the countries from where you accept trades, so that could also be used to isolate scam regions.

There have been a few other ideas how to prevent scammers but all those add usability drawbacks like the account verification as well as privacy concerns. Also its quite a bit of extra effort, so postponed to the point when we see that this becomes a real problem.

Finally I hope that most people move to use OKPay or othere payment methods which are less problematic as banks.

How does LocalBitcoins or Paxful deal with that issue?

But I still dont see why the locktime at the payout should not be sufficient protection.
If the victim requests a chargeback in between that period the scammer never gets the bitcoin, so that should avoid that they use Bitsquare for their scams. The locktime could be also user defined or amount dependent.

[AndreKoster]

The idea of a small initial transfer to verify bank accounts would work. It would create a sufficient delay, indeed.

I cannot say much about which countries are more popular. SEPA is very convenient for the scammers, since every victim in the EU can send SEPA payments. I don't have knowledge concerning other payment types regarding this. From my personal experience (mostly on Paxful), I'd say Germany and the Netherlands are countries favored by the scammers.

Platforms like LBC and Paxful can't do much about this type of scamming other than warn users. I can say that Paxful always has been very co-operative with me once I suspected to be dealing with a scammer (ruling in my favor when disputing a trade already done, immediately blocking the account of the scammer, providing the scammers' IP address). Other than that, they can't do much else.

The locktime doesn't help if contact between the victim and the seller cannot be established within the time of locking. I've never seen a chargeback happen. I have seen twice that the victim managed to cancel the transfer with his bank (after I informed or confirmed the victim that he had been scammed), if it's not processed yet. Depending on the bank, there is a window of a few hours to do that.

[HostFat]

What about requesting to the buyer to write a "payment reason/motive" on the SEPA transfer, something like:

"purchase of Bitcoin"
"purchase of tokens from [nickname]"
"purchase of tokens from [email]"
Better idea?

The scammer can't easily force the cheated user to write those kind of things on the SEPA transfer without giving him an hint that there is something strange happening.

[ManfredKarrer]

@AndreKoster:
I don't see why the victim cannot/would not make a chargeback. I don't know how long it takes but I assume that in such cases even banks are fast :-).
To open a communication possibility between traders would just invite those scammers to look out for social engineering victims on Bitsquare.
Even if we would allow interaction then the seller need to do a ID verification process, which is also not so easy to do without getting tricked, and beside that would be probably too much friction to use Bitsquare in the first place.
If the path to ID verification is required because of too much scams, then it must be done only once e.g. by the arbitrators, similar to the bank account verification.
But I see those measurements as last resort.
Another path would be a kind of insurance where victims of chargbacks can get a compensation, but that is not well thought through yet and insurances open up new doors for scams...
I also assume that those social engineering tricks will get harder over time as people learn and get better educated. The other threat with stolen bank acccounts is similar, its mostly possible as so many banks still don't have 2FA implemented or mandatory.

@HostFat:
I was thinking on something similar but if it is too clear that it was a BTC trade then some banks block accounts (have been some reports about that). The "purchase of tokens from" might work indeed, but I think some banks have very low restriction with the length of the reference text. It is usually just for IDs.
The current trade ID is of course not good enough to protect against such scenarios, but at least the scammer need to convince the victom to use that ID.
Email might not help much if the scammer managed to get control over the PC of the victim.

[HostFat]

I mean the [email](or [nickname]) of the seller.

The phrase needs to be something that the scammer can't easily make up, like:
"purchase of small yellow flowers from [email]" ([email] of the seller of Bitcoin)
The scammer will deed to find a victim that want to buy "small yellow flowers" from Internet, it's quite difficult :)

Or it will be impossible to make them (the possible victims) think that they are (the scammers) the true Microsoft support.

[ManfredKarrer]

@HostFat
Haha, thats an interesting idea...

[AndreKoster]

@ManfredKarrer
I'm not totally sure a chargeback is impossible with SEPA, but none of the six victims I've seen have done so. Your idea of bank account verification is the best so far. I agree that allowing communication opens the social engineering attack vector.

@HostFat
Explicitly naming Bitcoin or BTC in the reference field would help, but will give problems with some banks. Also, it requires the discipline to send money back if that reference is missing.

The SEPA bank account verification could also be made optional. Then you can let sellers choose themselves if they demand a verified account or not.

[HostFat]

@ManfredKarrer
Maybe you should add add a place on the creation of the "SEPA sell offer" where the seller ask the buyer to enter a text (or leave it empty) on the reason/motive. (it can be a special phrase as my examples or something like an ID)

Then the buyer will see this request while he is watching all the offers, he will choose to comply or not. (by choosing other offers ...)

[ManfredKarrer]

I think to add too early too much "pro-active" protection might confuse users too much and decrease usability and adoption.
I have seen that users have still problems with quite simple things. The concept of Bitsquare is a bit new so the user need to learn it and usability is hard to get right here. I think we should react once that becomes a problem.
The timelock is already implemented and can be actived with a new backward compatible release, so that could be deployed very fast. To improve the reference text can also be done any time. To add account verification would though requite a bit of work but if there is need for that that can be implemented also in 1-2 weeks.
There are other options as well, like marking countries which are known for much scam (Germany seems such a country - I got reports from another pro traders as well), so the users have by default those countries deactivated.
The trade limit will be another factor. 0.5 BTC as it is set now for SEPA is not much to attract at least stolen bank account scammers. Those social engineering scammers might operate with lower levels.
There is another idea which would be required anyway if we raise the trade limits (users demanded higher limits already):
The buyer need to pay an extra security deposit which is same as the trade amount and which will be locked long enough to react on chargebacks. So if you want to buy 10 BTC with SEPA you need to lock up 10 BTC which you get returned after e.g. 1 week. Of course people will not like to lock up so long money but that might be a safe way to get around those problems without introducing verifications, which will cause privacy and decentralization issues (arbitrators will become too important/powerful).
And altcoin exchanges have also their daily withdrawal limtis so if you have bought 10 BTC you cannot withdraw it in one day but need to do it over several days.

[AndreKoster]

There is time, indeed. It will only become an issue once bitsquare becomes significantly used.

Regarding the deactivation of certain taker countries, how is determined in which country a taker resides? If this happens by IP address, it's no good, since scammers usually work via VPN, and can be virtually in any European country irrespective of the country they target.

The main problem with the locking up BTC for a week is that even one week is not that long a time if a victim needs to a) realize he was scammed b) decide to take action c) report to the police d) have the police or bank trace the seller and e) have the seller raise a dispute on the (done) deal to seize the deposit. From personal experience I know the police takes weeks to get into action. Banks work much faster, but they don't share information. Hence, it's very unlikely the seller will get a signal in time about a specific deal. In the one case my bank account was blocked, this happened 9 days after the transfer -- and this was within the same country and with the victim and me having accounts at one and the same bank. If it then already took 9 days, how long a lock time is needed if two different bank are involved and if these are in two different countries?

[ManfredKarrer]

Re countries: When you setup your SEPA account you can define which countries you accept. Another user with a SEPA account from a country not in your list cannot take that offer. Of course he could ly about his country but if you as seller define that you don't accept buyers form Germany and you receive the bank transfer form a german bank than you should call the arbitrator and not confirm as it was not as defined in the trade contract.

Re locking up BTC:
Yes that sounds like a mess... Maybe when we ever get that problem, people have learned a bit and those scams don't work anymore. The 1 week was only an example, bu tof course to lock up for a month will never get accepted by users. The 1 week is also what OKPay uses, they might face similar issues as they say they never do chargeback.

[ManfredKarrer]

Another idea after discussions with @HostFat:

In nearly all banks (but not all) you can see the bank account and name from the fiat sender, so if we require that the seller confirms that the name and bank account data matches 100% with that what he received we should be fine. The scammer usually dont know the bank details and prob. even not the name of the victim.
Only those few banks where those data are not displayed (cannot image how that is possible in the 21th century) would be at risk, but I think that can be ignored, as if the scammers cannot expect a high success rate they will not use Bitsquare in the first place.

All what we need is displaying the buyers name and bank account data in the fiat receipt confirmation popup as well as an extra checkbox where he explicitely need to confirm he has checked that the buyers name and bank account data delivered from Bitsquare matches that what he seen at his bank. In doubt he should open a dispute.

What do you think? I sm y assumption correct that the scammer does not have knowledge to the victims bank account nr.?

[HostFat]

It can work, but the scammer can even try to social engineering the victim and asking him his details, and then try to buy an offer on Bitsquare with the information of the victim.

It's less easier, but I still think that your idea of putting even something like "Payment to Manfred Karrer (gdgk78dsf)" in the reason/motive of the SEPA is a good idea.

[AndreKoster]

@ManfredKarrer The scammer does have knowledge of the victims bank account number in the case of the Microsoft-virus-scam. The scammer sets up a remote control of the victim's computer, and follows the victim when he's making the transfer. I've received cam screenshots made at the time of submitting the transfer, of which victims later told me that they never made any -- they were made off the remote screen by the scammer.

@HostFat Regarding references, it would be best if the victim gets a hint from the reference that it does not refer to the scam service he thinks he bought. In that respect, a reference like "Bitcoin purchase gdgk78dsf" would be perfect. To evade evil banks, Bitcoin could be replaced by Bitsquare, or even Yellow tulips, as long as it doesn't make any sense in relation to a fake service rendered. Hence, just gdgk78dsf is too weak, as the scammers could still claim it to be their invoice reference.

The amount scammers typically go for is 300 euro, with 150 the minimum, and max. 350.

[HostFat]

@AndreKoster

My first idea was something like this:

gdgk78dsf Send to Manfred Karrer the JUMP YELLOW OUT LIQUID GOL

[REFERENCE-ORDER-ID] Send to [BUYER-NAME] the [5/6 random words]

[ManfredKarrer]

@AndreKoster
The scammer need to first do the trade (need to setup his payment account with the victims account data). So I assume that is much harder for him. But of course if he has the victims pc under full control he can do that as well.

@HostFat
What do you think about that?
Payment from Andre Koster to Manfred Karrer (gdgk78dsf)

Though if we use a special pattern it will become easy for banks to track Bitsquare trades.

[HostFat]

@ManfredKarrer
Yes, it's a better idea!

[haiqu]

The scam mentioned above is global and has been in use for over 10 years. I have been called here in Australia - usually by someone with an Indian accent - on numerous occasions.

We can't protect computer users from their own stupidity. If they think their ISP or Microsoft is going to call them at random they really have a low IQ. The best defence (apart from just hanging up) is to say you're busy, ask for a phone number and offer to call them back.

The verifed bank account using a small initial transfer has been utilized by Paypal since its inception, but they had a user base of millions of repeat users on eBay and could justify the effort. It also doesn't work unless you live in one location/country and intend to stay there.

[alexej996]

I think it is not that much harder to get a victims bank details when asking for money, claiming it is simply to know that you payed so that they don't need to call you back.
Maybe a seller can specify a random reason for payment as an offer requirement. There shouldn't be a distinct pattern since seller can adapt and think of a random reason for every trade if they wish.