![\"Polymarket](\"https:\/\/lh3.googleusercontent.com\/sitesv\/AG8ngQUIh2V_c_-eRwCpXPjhtvLrk9Dj7yPKbpcsWWQCgmq3Fw_cSdaEE6N2wWb69LIKxmNWRi0--PV6wQ9-rWWI9u8TQPPWmnIPZ1QmEMXhTrcLqFXpQfPOUXSTtmt8UUGrX9xMpf7yJqy9RtK1ftPQjLOI4hoas8dM0KdTVsx5b7BQlgK12W5wRROzzCxnY60AOo3J79Ygq1G6--K9Gv1ZpYA\")
<\/p>\nEin Benutzer \u00f6ffnet Polymarket zum ersten Mal und erwartet einen vertrauten Bildschirm: Benutzername und Passwort, eventuell ein Passwort-Manager-Symbol. Stattdessen sieht er drei unterschiedliche Authentifizierungsmethoden \u2013 Google OAuth, E-Mail mit Magic Code oder eine Kryptowallet. Kein klassisches Passwort, keine Passwort-Feld-Kombo, die nach jahrzehntelanger Normalit\u00e4t klingt. Das ist keine zuf\u00e4llige Designentscheidung. Es ist eine bewusste Abkehr von einem Sicherheitsmodell, das sich selbst widersprochen hat.<\/p>\n
Polymarket hat sich f\u00fcr eine Authentifizierungsarchitektur entschieden, die keine zentralen Passw\u00f6rter speichert, verwaltet oder sch\u00fctzen muss. Das klingt kontraintuiv, bis man versteht, dass Passw\u00f6rter nicht einfach nur unbequem sind \u2013 sie sind ein Sicherheitsproblem, das sich mit jeder neuen Attackvariante versch\u00e4rft. Die Wahl, auf traditionelle Passwortmechanismen zu verzichten, zeigt, wie Vorhersage-Marktpl\u00e4tze, die auf Blockchain-Technologie laufen, ihre Benutzer anders sch\u00fctzen k\u00f6nnen als zentrale Dienste. Dieser Artikel erkl\u00e4rt, warum dieser Verzicht kein Mangel ist, sondern ein Signal f\u00fcr die Zukunft der Authentifizierung im Web3.<\/p>\n
Das klassische Passwort ruht auf einer fehlerhaften Annahme: dass ein Benutzer ein langes, komplexes, zuf\u00e4lliges Geheimnis erschaffen, merken und verwalten kann \u2013 und dies f\u00fcr Dutzende von Diensten wiederholen muss. In der Realit\u00e4t f\u00fchrt das zu erwartbaren Problemen. Menschen verwenden kurze Passw\u00f6rter, wiederholen sie \u00fcber mehrere Plattformen, schreiben sie auf, teilen sie \u00fcber unsichere Kan\u00e4le oder vergessen sie. Jeder dieser Fehler ist nicht ein Versto\u00df gegen \u201eBest Practices”, sondern ein normales menschliches Verhalten unter unrealistischen Anforderungen.<\/p>\n
Das zentrale Problem ist, dass das Passwort der Angreifer geh\u00f6rt. Ein Datenleck bei einer Plattform, auf der der Benutzer ein Passwort eingesetzt hat, er\u00f6ffnet die M\u00f6glichkeit, dass gleiche Passwort bei anderen Diensten zu probieren \u2013 eine Attacke namens Credential Stuffing. Wenn der Service Passw\u00f6rter speichert, wird er selbst zum Angriffsziel. Selbst mit modernen Hashing-Verfahren wie bcrypt oder Argon2 bleibt die grunds\u00e4tzliche Wahrheit: ein zentraler Speicher mit millionen Passwort-Hashes ist ein wertvolles Ziel, das Angreifer aktiv anpeilen. Polymarket vermeidet dieses Problem strukturell, indem es kein Passwort speichern muss.<\/p>\n
F\u00fcr Plattformen, die Finanzinstrumente handeln \u2013 insbesondere Vorhersage-Marktpl\u00e4tze mit echtem Geld \u2013 ist diese Erkkenntnis nicht akademisch. Ein kompromittiertes Konto ist nicht nur eine l\u00e4stige Zur\u00fccksetzen; es kann zum direkten Verm\u00f6gensverlust f\u00fchren. Ein Angreifer, der Zugriff auf ein Handelskonto erh\u00e4lt, kann Positionen liquidieren, Guthaben abheben oder damit beginnen, Marktbewegungen zu simulieren, um andere Benutzer zu manipulieren. Das Passwort als Sicherheitsmodell ist f\u00fcr diesen Kontext zu fraglich geworden.<\/p>\n
Polymarket.com login bietet E-Mail-basierte Authentifizierung mit einem Magic Code<\/strong> oder Magic Link an. Der Ablauf: Benutzer gibt eine E-Mail-Adresse ein, erh\u00e4lt einen Link oder einen Code, klickt darauf oder gibt ihn ein. Das Passwort existiert nicht. Der Server muss kein Geheimnis speichern, das der Benutzer sich merken muss. Stattdessen wird ein zeitlich begrenzte Token generiert und an die E-Mail-Adresse des Benutzers geschickt.<\/p>\n Das funktioniert, weil es den Besitz des E-Mail-Kontos als Authentifizierungsfaktor nutzt<\/strong>. Wenn ein Angreifer einen Magic Link bekommen will, muss er entweder den E-Mail-Account kontrollieren oder den Traffic zwischen E-Mail-Provider und Browser abfangen. Beides ist schwieriger als ein Passwort zu raten oder aus einer gehackten Liste zu kopieren. Wenn eine Plattform gehackt wird, gibt es kein Passwort-Hash-Dump, das Millionen von Zugangsdaten enth\u00fcllt.<\/p>\n Google OAuth funktioniert \u00e4hnlich, aber delegiert die Authentifizierung an Google. Wenn ein Benutzer \u201eMit Google anmelden” w\u00e4hlt, wird er zu Google umgeleitet, meldet sich dort an (falls n\u00f6tig), und Google sendet dann ein Authentifizierungs-Token zur\u00fcck zu Polymarket. Polymarket speichert immer noch kein Passwort. Google speichert das Google-Passwort des Benutzers, nicht das Polymarket-Passwort. Das bedeutet: wenn Polymarket gehackt wird, hat der Hacker keine Google-Passw\u00f6rter. Der Benutzer hat ein Passwort bei Google zu verwalten statt eins bei jedem einzelnen Dienst.<\/p>\n Das ist kein perfektes System \u2013 Google wei\u00df jetzt, dass dieser Benutzer bei Polymarket angemeldet ist \u2013 aber es ist nicht dasselbe wie Passwort-Sicherheit. Die Attackfl\u00e4che ist anders gestaltet. Ein klassisches Passwort-System h\u00e4tte einen zentralen Speicher bei Polymarket; das OAuth-Modell hat eine Vertrauensbeziehung zu Google, aber nicht das Passwort selbst.<\/p>\n Die dritte Methode \u2013 Anmeldung mit MetaMask, Rabby oder Phantom \u2013 funktioniert v\u00f6llig anders. Diese Methode nutzt asymmetrische Kryptographie<\/strong>. Der Benutzer verbindet seine Wallet mit Polymarket. Der Server sendet eine Nachricht, die Wallet signiert diese Nachricht mit dem privaten Schl\u00fcssel des Benutzers, und Polymarket \u00fcberpr\u00fcft diese Signatur mit dem \u00f6ffentlichen Schl\u00fcssel des Benutzers. Wenn die Signatur g\u00fcltig ist, hat der Benutzer bewiesen, dass er den privaten Schl\u00fcssel dieser Wallet besitzt \u2013 ohne den Schl\u00fcssel jemals an Polymarket zu \u00fcbertragen.<\/p>\n Das ist das Sicherheits-Modell, das Bitcoin, Ethereum und andere Blockchains seit \u00fcber einem Jahrzehnt nutzen. Es hat sich bew\u00e4hrt, weil der private Schl\u00fcssel niemals die Wallet verl\u00e4sst. Der Benutzer unterschreibt auf seinem Ger\u00e4t, und nur die Signatur reist zum Server. Das bedeutet auch: selbst wenn Polymarket vollst\u00e4ndig gehackt w\u00fcrde, k\u00f6nnte der Angreifer nicht auf die Wallet des Benutzers zugreifen. Die Wallet-Authentifizierung ist nicht eine Art von Passwort-Ersatz \u2013 es ist ein strukturell anderes Sicherheitsmodell, bei dem der Benutzer private Schl\u00fcssel beh\u00e4lt und nur Signaturbeweise \u00fcbermittelt.<\/p>\n F\u00fcr einen Benutzer, der bereits eine Kryptowallet wie MetaMask oder Phantom besitzt, ist dies das nat\u00fcrlichste Authentifizierungs-Modell. Der Benutzer klickt \u201eMit Wallet verbinden”, best\u00e4tigt eine Nachricht in der Wallet-App, und ist angemeldet. Es gibt keinen Grund, sich ein neues Passwort auszudenken. Die Sicherheit ruht auf der Sicherheit der Wallet, die der Benutzer ohnehin bereits verwaltet.<\/p>\n Ein zentrales Passwort-System erfordert, dass der Benutzer einem Server vertraut, dass dieser das Passwort richtig speichert und sch\u00fctzt. Das ist theoretisch. In der Praxis speichern viele Unternehmen Passw\u00f6rter unter minimalen Standards, verwenden veraltete Hash-Funktionen, lagern Daten bei Drittanbietern, oder haben schlicht keine ausreichende Sicherheitskultur. Selbst gro\u00dfe, gut finanzierte Unternehmen haben regelm\u00e4\u00dfig Passwort-Leaks. Das ist nicht ein Versto\u00df gegen Best Practices \u2013 es ist das erwartete Ergebnis, wenn man Millionen von Passwort-Hashes zentral speichert.<\/p>\n Die Magic-Link- und Wallet-Modelle verschieben diese Last. Bei Magic Links muss Polymarket zwar einen Token speichern, aber dieser Token ist zeitlich begrenzt und f\u00fcr einen einzigen Gebrauch bestimmt. Wenn das Token gehackt wird, ist es morgen wahrscheinlich nicht mehr g\u00fcltig. Bei Wallet-Authentifizierung muss Polymarket nicht einmal das Token speichern \u2013 es kann den privaten Schl\u00fcssel des Benutzers nicht verwenden, selbst wenn es wollte. Der Server sieht nur die \u00f6ffentliche Wallet-Adresse und eine Signatur, die nur beweist, dass der Benutzer diese Adresse kontrolliert.<\/p>\n Das ist ein Vertrauens-Modell, das dem klassischen Passwort \u00fcberlegen ist. Es sagt nicht: \u201eVertraue uns, dass wir dein Geheimnis sch\u00fctzen.” Es sagt: \u201eWir halten dein Geheimnis gar nicht erst. Beweise uns mit Kryptografie, dass du derjenige bist, der du sagst, dass du bist.”<\/p>\n Ein h\u00e4ufiges Missverst\u00e4ndnis ist, dass ein gutes Authentifizierungs-Modell vor Phishing sch\u00fctzt. Das tut es nicht \u2013 oder nur teilweise. Ein Phishing-Angreifer kann eine gef\u00e4lschte Polymarket-Website erstellen und versuchen, den Benutzer dazu zu bringen, dass dieser seinen Google-Account oder seine Wallet dort \u201everbindet”. Das Problem ist nicht das Authentifizierungs-Modell; das Problem ist, dass der Benutzer auf der falschen Website ist.<\/p>\nKryptowallet-Authentifizierung und verifizierbare Besitzverh\u00e4ltnisse<\/h2>\n
Das Vertrauens-Problem bei zentralisierten Passwort-Servern<\/h2>\n
Phishing und die Grenzen der Authentifizierung<\/h2>\n