Was sind die Best Practices, um die Registrierung und Anmeldung von Benutzern für eine DApp zu ermöglichen?

Nach dem, was ich recherchiert habe, scheint es, dass alle Methoden, mit denen sich ein Benutzer für eine Ethereum-Dapp anmelden und anmelden kann, für den Benutzer sehr umständlich zu verwenden sind. Was sind die Best Practices, um Anmeldungen und Anmeldungen zuzulassen, die die folgenden Kriterien erfüllen:

  1. Die Methode zur Anmeldung und Anmeldung sollte nicht umständlich sein; dh: einfache wie normale Methoden von Benutzername/Passwort oder Facebook und Google oauth.

  2. Die Methode zur Anmeldung sollte dem Benutzer kein Ethereum (Gas) in Rechnung stellen - das Geld von jemandem nur für die Anmeldung zu nehmen, würde die meisten Leute abschrecken.

  3. Die Methode der Registrierung und
    Anmeldung sollte den Benutzer nicht dazu bringen, durch Reifen zu springen,
    wie z . usw.


  4. Zusätzliche Software wie MetaMask oder Mist sollte nicht erforderlich sein. (Vielleicht ist das nicht möglich?)

Das Ziel hier ist es, so viele Hürden wie möglich zu beseitigen, um Benutzer zur dapp zu bringen.

Antworten (4)

AFAIK, es ist immer einfach und gut, den PGP-Schlüsselmechanismus für die Benutzerauthentifizierung in DAPPs zu verwenden, die mit Ethereum erstellt wurden. Es ist möglich, die Kontoadresse als Benutzernamen zu verwenden und den Benutzer zur Überprüfung einige Daten mit seinem privaten Schlüssel signieren zu lassen. Dieser Artikel könnte Ihnen dabei helfen.

Um es Benutzern einfach zu machen, können Sie Benutzern erlauben, ihren privaten Schlüssel auf der Seite des Clients zu speichern (z. B.: ihn in die App einbetten, die sie nach der Registrierung verwenden usw.). ist deinstalliert)

UPDATE : Wie in den Kommentaren unten besprochen, verwenden Sie, wenn Sie sich für ein herkömmliches Benutzerkontosystem entscheiden möchten, eine herkömmliche Benutzertabelle mit Benutzernamen, die einer Kontoadresse zugeordnet sind, und verwenden Sie web3.js (siehe diese Frage ) , um eine Verbindung zum Ethereum-Netzwerk herzustellen Dies geht wiederum für einen vertrauenswürdigen Mechanismus eines Drittanbieters.

Vielleicht ist Ethereum zu unreif für das, was ich anstrebe. Es wird einfach nicht funktionieren, Ihre durchschnittliche normale Person, Nicht-Entwicklertypen, bitten zu müssen, Chrome-Erweiterungen zu installieren. Für mich ist das das größte Problem, mit dem Ethereum und andere Blockchain-Technologien konfrontiert sind – die Umstellung der Person, die an das normale Internet gewöhnt ist, auf das dezentrale Blockchain-Internet, wo ihr Profil nicht mehr ein Benutzername/Passwort, sondern ein Hash-String-Token ist die Anschrift.
Ja, Ethereum ist wirklich cool für uns Entwickler-Typen. Ansonsten scheint all diese Technik für Ihren normalen durchschnittlichen Facebook-Benutzer viel zu unpraktisch zu sein.
Warum nicht eine normale Kontotyp-Benutzernamenzuordnung zu Kontoadressen und ein Passwort verwenden, um den privaten Schlüssel zu überprüfen. Möglicherweise müssen Sie die Zuordnung serverseitig vornehmen. Das Problem ist jedoch, dass dies so aussehen könnte, als hätte man einen vertrauenswürdigen Dritten, für den das Blockchain-Konzept nicht konzipiert ist.
OK Nehmen wir an, ich verwende zum Beispiel einen serverseitigen Knoten. Wie würden Sie 1) mit dem Ethereum-Netzwerk kommunizieren 2) das Profil eines Benutzers mit seiner Ethereum-Wallet-Adresse verknüpfen? Würden Sie einfach danach fragen, nachdem sie sich angemeldet haben?
für Nr. 2 pflegen Sie eine Benutzertabelle und speichern Sie die Brieftaschenadresse mit ihrem Benutzernamen in Ihrem Backend
ok ich denke das könnte funktionieren. Können Sie Ihre Antwort mit dem aktualisieren, was wir entdeckt haben?
Meine Frage ist jetzt: "Welchen Mechanismus verwenden Sie zur Validierung der Wallet-Adresse, die der Benutzer Ihnen in der Benutzeroberfläche gibt?" Darauf kann man sich offensichtlich nicht verlassen.
Auch wenn er eine falsche Brieftaschenadresse angibt, muss er die Passphrase (zugehörig zu seinen Schlüsseln) angeben, um das Konto zu entsperren, wenn die Entsperrung des Kontos fehlschlägt. Dies kann zur Verifizierung verwendet werden
Sie könnten sich auf bestehende Authentifizierungsmechanismen verlassen und Schlüssel in der Cloud für den Benutzer generieren. Unterschreiben Sie dann Offline-Transaktionen. Ich habe eine kleine Bibliothek erstellt, die Transaktionen mit Azure Key Vault signieren kann. Benutzer können mit jedem unterstützten OAuth authentifiziert werden und ihre Schlüssel werden in der Cloud verwaltet. Nur eine Idee. npmjs.com/package/ethereumjs-tx-keyvault
@TomislavMarkovski tolle Sachen. wird sehr nützlich sein :)

Punkt 4 ansprechen: Es ist definitiv möglich, aber Sie müssen sich zwischen einem vollständig zentralisierten und einem dezentralisierten Ansatz entscheiden.

MetaMask ist dezentralisiert (Endbenutzer besitzen die privaten Schlüssel), aber die Chrome-Erweiterung erfordert, dass Benutzer mehr Hürden überwinden, um loszulegen.

Es gibt etwas zentralisiertere Lösungen wie Fortmatic , die es Endbenutzern ermöglichen, direkt mit Dapps in jedem Browser zu interagieren, ohne eine Chrome-Erweiterung herunterladen zu müssen.

Es gibt im Allgemeinen nicht viel Traktionsstrom für Dapps – ich würde mich lieber dafür entscheiden, ein besseres Benutzererlebnis zu bieten und Traktion für Ihre App zu erhalten, bevor ich erwäge, einen dezentralen Ansatz als Option hinzuzufügen.

Sie können eine Ethereum-Adresse als eindeutige Kennung für ein Benutzerkonto verwenden. Sie können dann verlangen, dass der Inhaber des privaten Schlüssels, der dieser Adresse zugeordnet ist, eine Nachricht signiert, die Sie dann überprüfen können.

Es ist möglich, zu überprüfen, ob eine Nachricht mit einem bestimmten privaten Schlüssel signiert wurde, ohne den privaten Schlüssel zu kennen .

Ich habe vor einiger Zeit einen Blogbeitrag über das Signieren einer Nachricht geschrieben .

Das Problem bei diesem Ansatz ist die Einfachheit und die Akzeptanz durch die Gemeinschaft. Ich habe zuvor ein Anmeldeprotokoll erstellt, das wie oben beschrieben funktionierte. Das Problem besteht darin, dass entweder eine von Ihrer DAPP unabhängige Nachricht signiert werden muss (komplex, Eintrittsbarriere) oder dass der Benutzer seinen privaten Schlüssel in irgendeiner Form (roh, Schlüsseldatei, Mnemonik usw.) für Ihren Dienst bereitstellt, damit Sie die Nachricht bereitstellen können Unterzeichnung.

Als ich das tat, wurde die 'Community' wütend, weil es ein Sicherheitsrisiko darstellte (wäre ich ein Betrüger).

TL;DR; Es ist machbar, aber alle werden über Sicherheit/Dezentralisierung stöhnen.

Ich weiß, der Thread ist zu alt, aber da ich vor dem gleichen Problem stand, möchte ich darauf antworten.

Das Konzept der digitalen Signatur, das Blockchain verwendet, ist eine sehr bekannte Technologie, aber leider wird es von normalen Menschen (z. B. Facebook-Benutzern) nicht verwendet. Stellen Sie sich eine mobile Authentifikator-App vor, die folgende Funktionen hat:

Komponenten:

  • Eine Authentifizierungs-App
  • Dapp-Server
  • AuthServer

Anmeldung:

  • Der Benutzer besucht die Dapp-Registrierungsseite und scannt einen QR-Code mit einer Challenge-Zeichenfolge (generiert auf dem AuthServer).
  • Ein kryptografisches Schlüsselpaar wird mit demselben Protokoll generiert, das die Blockchain verwendet.
  • Der Benutzer signiert die Challenge mit privatekey und sendet Folgendes an DappServer: publickey, userdata, digitalsig (DS)
  • DappServer speichert Benutzerinformationen und leitet den DS und den öffentlichen Schlüssel an AuthServer weiter
  • Der Benutzer ist registriert

Anmeldung:

  • Der Benutzer scannt den QR-Code von der Anmeldeseite -> signiert die Nachricht (die Herausforderung) und sendet den öffentlichen Schlüssel DS an DappServer
  • DappServer überprüft, ob der Benutzer existiert, und leitet dann die digitalSig-Verifizierungsanforderung an den AuthServer weiter
  • Der AuthServer verifiziert den DS und sendet basierend auf dieser Entscheidung die Antwort an DappSErver – ein Benutzer ist angemeldet.

Transaktionssignierung:

  • Die Transaktion wird auf der Dapp gebildet und als QR angezeigt
  • Der Benutzer generiert ein neues Schlüsselpaar (dieses Schlüsselpaar kann mit demselben Algorithmus generiert werden, der für die LoginKeyPair-Generierung verwendet wurde)
  • Der Benutzer scannt den QR-Code und unterzeichnet die Transaktion
  • Der Benutzer sendet das signierte TX an DappServer, der es dann an das Netzwerk sendet.

Notiz:

  • Wie Sie hier sehen können, befindet sich der gesamte Trust auf AuthServer, aber man kann sich den AuthServer als Smart Contract mit nur einer Methode vorstellen, nämlich der bool verifyDigitalSig(digitalSig, publikey)Getter-Methode.
  • Was wir gelöst haben, ist, dass der Benutzer nur für die Anmeldung nichts bezahlen muss.
  • Dies ist ein login-firstAnsatz im Gegensatz zu wallet-first.

Sehen Sie, ob dies hilft.