[ingan.elements] Idea to prevent fraud

in hive-151113 •  7 months ago 

I just released the new steem dapp in which users can buy and sell steem accounts.
https://elements.ingan.live

But there is a serious problem regarding a fraud.

Let say if you want to buy this account which is 50K STEEM, which is a lot of money.


We can imagine that the seller of this account tries to scam to a buyer. @moecki raised this issue.


When moecki raised this question, I forgot that I did not handle this problem. Thank you moecki again.

As the response of moecki's question, I answered like this:

  1. The purchaser sends the amount of steem to the service account (escrow)
  2. The purchaser gets the master password of the account
  3. The purchaser changes the password.
  4. Then 'account_update' transaction can be detected and the service account transfers the amount of steem to the seller.

This was my initial thought but it is not easy to implement since the detection of a specific transaction is a budden.

I confirmed that this detection is possible before answering this question.


As you can see in the above image, it is possible to detect the account update transaction by the purchaser.

But I noticed that this solution is not good since it has to wait until this transaction happens. And what if there are several transactions to track? it will be very inefficient.

I came across a new good idea, which is simpler and no need to track the update transaction.

Here is the idea

  1. The seller registers the account with the master password.
  2. The purchaser transfers the amount of steem to the service account when buying the account.
  3. At the moment of the purchase, the app changes the master password to a new one using the initial private owner key.
  4. Then, the purchaser gets the new password and the old password is not valid anymore.
  5. The service account transfers the amount of steem to the seller.
  6. Refund the amount to the purchaser if an error occurs during this process.

This process is simpler than tracking the update transaction. If you find any flaw in this process, please let me know.

I will start implementing this feature soon.

By the way, moecki mentioned the situation in which this service is useful.

We had liked to have the account @dubby for our @du-finanzbot of our community (Deutsch Unplugged)

If you know the owner of this account @dubby, please let he/she know moecki wants to buy the account.

Thank you.

cc.
@pennsif
@steemcurator01

Posted through the ECblog app (https://blog.etain.club)

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  
  ·  7 months ago (edited)

Your new procedure sounds simpler, but I am not yet convinced that this can prevent fraud.

The master password is not stored anywhere in the chain. The other keys are only derived from the master password. I would therefore assume that I can also undo the "change" of the master password with a recovery.

I'll have to take a look at this in the steemd code and test it... if I have time to do so...

I would therefore assume that I can also undo the "change" of the master password with a recovery.

That is correct. I went through the process here 4 years ago, the procedure is probably still the same.

My estimate: it takes 30 days until an account can be transferred safely, i.e. without the risk of a recovery from the owner.

The important thing is, the recovery account starts the process. If this is @steem, then as far as I know the current Top1 Witness is responsible for this, otherwise the registered account. A change to the recovery account only becomes effective after 30 days. If the seller has registered one of his own accounts here, he can recover the sold account within 30 days.

What I don't know is whether there is a limit to how often the master password has to be changed before recovery is no longer possible. However, I strongly assume that the password could be changed at will and that a recovery is possible within 30 days regardless of this. Otherwise this whole mechanism would be pointless.

Also, I don't know the exact process if @steem is the recovery account. There might be a chance to shorten the process here if @steem or the top1 witness would be willing to not start recovery from sold accounts.

Otherwise I don't see any possibility and that's how it should be for security reasons.

Vielen Dank für den Hinweis auf dein Tutorial. So wie du es beschrieben hast, scheint es ja immenoch zu funktionieren. Steemchillers Seite finde ich (auch) dafür jedenfalls total klasse.

Die Recovery-Funktion ist auf jeden Fall sinnvoll und sollte auch beibehalten werden. Keine Frage! Ich denke auch nicht, dass er da Steemit mit ins Boot holen sollte. Umso mehr Leute da involviert sind, umso weniger vertrauenswürdig wird mir das.
BTW: Ich habe mir auch einen zweiten Account für das Recovery angelegt... und den Recovery-Account noch nicht geändert... Frevel :-)

What I don't know is whether there is a limit to how often the master password has to be changed before recovery is no longer possible.

Wie ich schon schrieb, kennt das Master-Passwort nur der User selbst (wenn er entsprechend darauf aufpasst). Auch die Chain kennt diesen (oder einen Hash davon) nicht. Aus dem Master-Passwort werden lediglich die anderen Keys abgeleitet. Die PublicKeys werden dann in den Account-Daten eingetragen. Damit kann dann wirksam überprüft werden, ob du den richtigen PrivateKey irgendwo eingetragen hast. Aber ich vermute, das weißt du alles (habe es nur aufgeschrieben, falls jemand anderes mitliest). Für die Chain sieht die Änderung des Master-Passworts also so aus, als wenn ich alle vier Keys geändert habe. Mit dieser Herleitung würde ich insofern sagen, dass die Anzahl der Passwortänderungen keine Rolle spielt bzw. nicht begrenzt ist.
Für mich ist nur offen (und deshalb meinte ich, man müsste sich das im Code anschauen), woher die Chain dann einen gültigen (alten) OwnerKey erkennt. In der FAQ ist beschrieben, dass für das Recovery ein in den letzten 30 Tagen gültiger OwnerKey angegeben werden muss. Theoretisch könnten es also mehrere gültige sein... Spannend! :-)

Theoretisch könnten es also mehrere gültige sein...

Wird wohl so sein, wobei man normalerweise sein Passwort nicht alle Tage ändert. Da bin ich bei meinem Testlauf auch etwas ins Schwimmen gekommen, weil ich den public Ownerkey nicht gesichert hatte. Dafür gibt es beim Steemworld Recovery jetzt unten die Owner Key History. Praktisch!

Ich stricke gerade eine Theorie, wenn dem so ist, was ich noch nicht vollends durchdacht habe, dann müssten wir hier evtl. etwas aufpassen, um nicht potenziellen Dieben eine Vorlage zu liefern.

Aber, da muss ich nochmal drüber schlafen...

weil ich den public Ownerkey nicht gesichert hatte

Den hättest du dir auch mit dem Masterpasswort erneut generieren können.

Ich stricke gerade eine Theorie

Da bin ich gespannt. :-)
Im Übrigen hast du recht. Bei der ganzen Diskussion besteht natürlich die Gefahr, dass Betrüger sich die Gedanken zu nutze machen und unbedarfte User übers Ohr hauen... oder unbedachte Lücken ausnutzen... insofern: lass dir Zeit.

Hab dir auf Discord eine DM geschickt. Mal guggen ob das ankommt, aktuell meint das Teil: nicht zustellbar.

Schick die mal bitte auf meinen Hauptaccount: moecki. Du hast den "Behelfsaccount" angeschrieben.

thank you for sharing your thoughts. I wall also look into the 'recovery thing'.

  ·  7 months ago (edited)

I have thought a little about the problem.

I think the only way to handle this safely at the moment would be to wait 30 days + x hours.
I could imagine the following procedure (the new steps are in italics):

  1. The seller registers the account with the master password.
  2. The app assigns a new master password and then changes (only) the OwnerKey (so that the seller can continue to use the account).
  3. The waiting period of 30 days + x hours (recovery window plus x hours for safety) begins.
  4. The account is displayed as "reservable" in the app. After the waiting period has expired, the account is displayed as "available for sale".
  5. The purchaser transfers the amount of steem to the service account when buying the account.
    At the moment of the purchase, the app changes the master password to a new one using the initial private owner key.
  6. Wait until the waiting period has expired.
  7. Then, the purchaser gets the new password and the old password is not valid anymore.
  8. The service account transfers the amount of steem to the seller.
  9. Refund the amount to the purchaser if an error occurs during this process.

As an option, you could also offer a risk variant for the buyer, where the waiting period can be explicitly deactivated...

So, now it's your turn :-)

Thank you for your idea. Now I know how the account recovery works.

What if the recovery account is changed to something else owned by the buyer at the time of purchase?

Then, the seller cannot try to recover the account. right?

I think so, but changing the recovery account also takes 30 days. The old recovery account is valid for this period. For your purpose, changing the recovery account immediately at the time of purchase would therefore not bring any advantage.
You can see this with my account (Account Details on https://steemworld.org/@moecki). I changed the recovery account today.

thank you for the test.

  ·  7 months ago (edited)

Warum kauft man ein Konto , das ist doch was persönliches,oder
@moecki 🙄 @etainclub 🙄.?
VgA

Das ist in etwa so wie Domains zu verkaufen.
Du möchtest einen bestimmten Accountnamen haben, stellst dann aber fest, dass der schon vergeben ist. In dem Fall wäre so eine Verkaufsoption schon praktisch.

Ok , ich habe mir schon Gedanken gemacht und kam dann drauf das es wohl um den Namen geht
VgA

Thank you, friend!
I'm @steem.history, who is steem witness.
Thank you for witnessvoting for me.
image.png
please click it!
image.png
(Go to https://steemit.com/~witnesses and type fbslo at the bottom of the page)

The weight is reduced because of the lack of Voting Power. If you vote for me as a witness, you can get my little vote.

This post has been featured in the latest edition of Steem News...