Login mit PGP statt E-Mail: wie das Verfahren aus dem Darknet funktioniert und was es taugt (2026)

Beim Login mit PGP meldet sich ein Mensch mit seinem Schlüsselpaar an statt mit E-Mail-Adresse und Passwort. Der Dienst kennt nur den öffentlichen Schlüssel; angemeldet ist, wer einen damit verschlüsselten Zufallscode entschlüsseln kann. Auf Darknet-Märkten ist das seit mindestens 2016 belegt, dort meist als zweiter Faktor nach dem Passwort, bei Konten ohne E-Mail-Adresse. Für diesen Schritt speichert der Betreiber kein Geheimnis, und ohne E-Mail-Adresse fällt das Zurücksetzen über das Postfach weg. Zwei Grenzen sind belegt: Wer den entschlüsselten Code abtippt, ist nach der Definition des US-Standardinstituts NIST nicht vor Phishing geschützt, und wer den privaten Schlüssel verliert, verliert das Konto. Außerhalb des Darknets läuft dasselbe Prinzip unter anderem Namen seit Jahren: SSH-Login, signierte Git-Commits, Paket-Signaturen bei Debian.

Stand aller Angaben: 13.10.2026. Grundlage sind Studien zu Darknet-Märkten aus den Jahren 2019 bis 2025, Standards von NIST, W3C und IETF sowie Dokumentationen der Hersteller. Beschrieben wird das Verfahren, nicht der Zugang zu Marktplätzen.

Beim PGP-Login beweist der Besitz des privaten Schlüssels die Identität

Der Ablauf ist in allen ausgewerteten Quellen gleich [1][2][3]:

1. Beim Einrichten lädt der Nutzer seinen öffentlichen PGP-Schlüssel ins Profil.

2. Beim Anmelden erzeugt der Server einen Zufallscode, verschlüsselt ihn an diesen Schlüssel und zeigt den verschlüsselten Block an.

3. Der Nutzer entschlüsselt den Block mit seinem privaten Schlüssel im eigenen Programm und gibt den Code zurück.

4. Stimmt der Code, ist bewiesen, dass der Nutzer den privaten Schlüssel besitzt.

Auf dem Markt AlphaBay war das laut VICE 2016 für Verkäufer Pflicht, für Käufer freiwillig; der Code hatte 16 Zeichen [1]. Wang und Kollegen untersuchten 12 Märkte mit Daten von Mai bis August 2023. Die Registrierung fragte weder E-Mail-Adresse noch Telefonnummer ab, der zweite Faktor lief meist über PGP, und 9 der 12 Märkte gaben eine Wortliste zur Wiederherstellung aus [2]. Güldenring und Roth von der FU Berlin prüften von September bis November 2023 100 erreichbare Onion-Dienste und fanden PGP als zweiten Faktor bei 10, Einmalcodes per App (TOTP) bei 6 [3]. Jüngere Zahlen als von 2023 enthält keine der ausgewerteten Studien.

Auf Darknet-Märkten ist der PGP-Schlüssel die Identität, die von Markt zu Markt mitzieht

Märkte schließen und neue entstehen, Verkäufer ziehen um, Betrüger kopieren bekannte Namen. Dwyer und Kollegen werteten Forenbeiträge von fünf Märkten aus den Jahren 2013 bis 2015 aus. PGP diente zur Anmeldung in den Foren und vor allem dazu, Verkäufer über Märkte hinweg wiederzuerkennen. Wer einem Verkäufer misstraute, verlangte, eine Nachricht an dessen älteren Schlüssel zu entschlüsseln [4]. Tai, Soska und Christin von der Carnegie Mellon University zählten in Daten aus acht Jahren 28.417 PGP-Schlüssel auf 32.101 Konten; manche Verkäufer nutzten denselben Schlüssel auf mehreren Märkten [5].

Dieselben Autoren nennen zwei Einschränkungen. Ein veröffentlichter öffentlicher Schlüssel beweist nichts, ein Hochstapler kann ihn einfach auf seine Seite kopieren. Erst die gelöste Challenge beweist den Besitz. Außerdem verlieren Menschen häufig den Zugang zu ihrem privaten Schlüssel und erzeugen aus legitimen Gründen neue [5].

Im E-Mail-Web kann jeder, der das Postfach kontrolliert, das Passwort zurücksetzen

Die E-Mail-Adresse als Generalschlüssel des Webs ist eine Zuspitzung. Belegbar sind ihre Bausteine. Ein vergessenes Passwort wird laut OWASP über einen zweiten Kanal zurückgesetzt, typischerweise per Link in einer E-Mail [6]. Bei Magic Links, etwa in der Login-Bibliothek Auth.js, ist die Mail der einzige Weg hinein; der Link gilt 24 Stunden [7]. NIST verbietet E-Mail in der Richtlinie SP 800-63B-4 (August 2025) als Anmeldefaktor, weil ein Postfach oft nur mit einem Passwort geschützt ist und Mails unterwegs abgefangen oder umgeleitet werden können. Codes per E-Mail zur Wiederherstellung erlaubt dieselbe Richtlinie ausdrücklich [8].

Dazu kommt der Anbieter. Sperrt Google ein Konto, kann sich der Nutzer laut Google-Hilfe weder bei Google-Diensten anmelden noch „Mit Google anmelden“ verwenden [9]. Die New York Times berichtete 2022 über einen Vater, dessen Google-Konto nach einem Foto für den Kinderarzt automatisch als Missbrauchsmaterial eingestuft und gesperrt wurde; mehr als zehn Jahre Kontakte, Mails und Fotos waren weg [10]. Have I Been Pwned listete am 13.10.2026 1.044 Datenlecks mit zusammen 17.845.803.111 betroffenen Konten. Gezählt sind Konten, nicht Personen [11].

Passkeys und Nostr binden den Schlüssel-Login an die Domain des Dienstes, der PGP-Login meist nicht

Passkeys (Standard WebAuthn) arbeiten im Kern wie der PGP-Login. Der Dienst speichert einen öffentlichen Schlüssel, der private bleibt beim Nutzer, angemeldet wird per Challenge, ein gemeinsames Geheimnis gibt es nicht. WebAuthn Level 3 ist seit dem 25.08.2026 Empfehlung des W3C. Jeder Passkey gilt nur für die Domain des Dienstes, und das prüft der Browser, nicht der Mensch [12]. Synchronisiert werden Passkeys meist über Plattformkonten wie den iCloud-Schlüsselbund oder den Google-Passwortmanager [13][14].

Die Angabe, Passkeys säßen beim Plattformanbieter fest, ist 2026 überholt. Das Credential Exchange Protocol der FIDO Alliance erlaubt den Umzug zwischen Passwortmanagern laut Bitwarden seit iOS 26 (15.09.2025) und seit dem 23.07.2026 auch unter Android [15]. Ob die Spezifikation als Entwurf oder final gilt, weist die FIDO-Seite nicht aus.

Nostr macht den Schlüssel selbst zur Identität: Jeder Nutzer hat ein Schlüsselpaar, jede Nachricht ist signiert (NIP-01). Zum Anmelden signiert der Nutzer ein Ereignis mit der Challenge und der Adresse des Relays (NIP-42) oder mit der exakten URL und HTTP-Methode (NIP-98). Den privaten Schlüssel hält eine Browser-Erweiterung (NIP-07) oder ein entfernter Signierdienst (NIP-46), die Webseite bekommt ihn nie. Alle genannten Spezifikationen tragen den Status „draft“ [16]. Damit steckt die Adresse des Dienstes im Beweis; beim PGP-Login nach Darknet-Vorbild ist das nicht vorgeschrieben.

Quellen der Tabelle: [2][3][8][12][13][16][22].

Abgetippte Codes sind nicht phishing-fest, die Challenge braucht eine signierte Domain

NIST stuft jedes Verfahren, bei dem ein Mensch eine Ausgabe von Hand eingibt, als nicht phishing-resistent ein: Eine gefälschte Prüfstelle kann die Ausgabe an den echten Dienst weiterreichen [8]. Ein abgetippter PGP-Code fällt darunter; das ist eine Ableitung, NIST nennt PGP nicht. Güldenring und Roth kommen unabhängig zum selben Ergebnis. Eine Phishing-Seite kann die verschlüsselte Challenge des echten Dienstes durchreichen; schützen kann nur eine Challenge, die den echten Domainnamen enthält und vom Dienst signiert ist [3].

Bei 8 Diensten, auf denen die beiden Forscher den PGP-Zweitfaktor selbst einrichteten, enthielt die entschlüsselte Challenge 4-mal nur den Code, 1-mal Code und Domain ohne Signatur, 1-mal eine signierte Domain plus unsignierte Login-Adresse und 2-mal Code und Domain mit Signatur [3]. VICE schrieb 2016, manche Darknet-Märkte hätten bessere Sicherheit für Nutzer als Gmail [1]. Die Messung von 2023 zeigt: Ein Pflicht-Zweitfaktor per PGP ist nicht dasselbe wie Schutz vor Phishing.

Ein weiteres Risiko ist für den Login in keiner ausgewerteten Quelle beschrieben, folgt aber aus dem OpenPGP-Standard. RFC 9580 nennt historische Angriffe, bei denen ein Nutzer eine Nachricht arglos entschlüsselt, den Klartext zurückgibt und so zum Entschlüsselungsorakel wird [22]. Ein Login nach dem Muster „entschlüssele und gib den Klartext zurück“ hat diese Form: Eine gefälschte Seite könnte statt eines Zufallscodes eine abgefangene echte Nachricht vorlegen. Ein konkreter Fall ist nicht belegt. Verfahren, die eine Signatur verlangen, haben das Muster nicht.

Wer den privaten Schlüssel verliert, verliert das Konto

Ohne Postfach gibt es keinen Link zum Zurücksetzen. Damit entfällt der Kontoklau über die Mail, und ebenso der Rettungsweg. Auf AlphaBay war ein Konto ohne die Merkliste aus sieben Wörtern laut VICE „lost forever“ [1]. Der Passwortmanager Passbolt, der Teams per PGP anmeldet, nennt als Auswege ein Recovery-Kit, also eine Datei mit dem privaten Schlüssel, oder ein verschlüsseltes Server-Backup mit Freigabe durch einen Admin, sofern die Organisation es eingerichtet hat [17]. Bei der Videoplattform AVideo entfernt ein Admin den verlorenen Schlüssel, danach reicht wieder das Passwort [24].

Auch die Aussage, beim Betreiber liege nichts, stimmt nur halb. Er speichert öffentlichen Schlüssel und Fingerabdruck. Wer diese Liste und später den privaten Schlüssel einer Person erbeutet, kann nachweisen, dass sie den Dienst genutzt hat [3].

Jeder Dienst baut den PGP-Web-Login anders, und er ist selten: 6 von 778 Anmeldungen bei IndieLogin

OpenPGP selbst ist standardisiert, seit Juli 2024 in RFC 9580, der RFC 4880, 5581 und 6637 ersetzt [22]. Anleitungen mit Verweis auf RFC 4880 beschreiben den alten Stand. Das GnuPG-Lager pflegt daneben mit LibrePGP einen eigenen Entwurf mit älterem Schlüsselformat [33]. Den Anmeldeablauf regelt keiner dieser Texte. Güldenring und Roth fanden ihn auf jeder Website anders umgesetzt [3]. Ein Standard für den Web-Login per PGP fand sich in der Recherche nicht (gesucht: IETF-Datatracker, Dokumentation von Passbolt und IndieLogin).

IndieLogin.com, ein offener Login-Dienst, veröffentlicht Zahlen: Im September 2026 liefen dort 778 Anmeldungen, davon 6 per PGP, 106 per E-Mail, 199 per GitHub und 257 per IndieAuth [23]. Das ist ein einzelner Dienst mit technisch interessiertem Publikum und nicht übertragbar. Yubico schreibt in der eigenen Entwicklerdoku: „PGP is not used for web authentication.“ [21]

Zur Bedienbarkeit liegt in den ausgewerteten Quellen eine einzige Nutzerstudie vor: Eine Masterarbeit an der Carleton University testete 2015 eine Browser-Erweiterung für PGP-Login mit 12 und 16 Teilnehmenden, überwiegend Studierenden. Der zweite Prototyp erreichte auf der System Usability Scale 75,78 Punkte; verwirrend fanden die Teilnehmenden das Verknüpfen und Signieren der Schlüssel [18]. Latacora schrieb 2019, das Identitätsgerüst von PGP funktioniere nicht, normale Menschen vertrauten allem, was wie ein PGP-Schlüssel aussehe [19]. Robert J. Hansen hielt im GnuPG-Blog im März 2026 dagegen: Ein Teil der Kritik sei Halbwahrheit, und die berechtigten Einwände, die Matthew Green 2014 erhoben hatte, entschärften die neuen Spezifikationen größtenteils [20].

SSH, Git, Debian und der Linux-Kernel binden Identität seit Jahren an Schlüssel

Beim SSH-Login ist „publickey“ laut RFC 4252 von 2006 die einzige Pflichtmethode. Der Besitz des privaten Schlüssels ist die Anmeldung, bewiesen durch eine Signatur, die unter anderem die Kennung der laufenden Verbindung einschließt [27]. Das ist eine Bindung an den Kanal, eine der beiden Formen, die NIST als phishing-resistent anerkennt [8]. OpenPGP-Schlüssel kennen neben Signieren und Verschlüsseln die Fähigkeit Authentifizieren [29], und GnuPG arbeitet auf Wunsch als SSH-Agent [28].

GitHub markiert Commits und Tags, die mit GPG, SSH oder S/MIME signiert sind, als „verified“ [32]. Der Linux-Kernel zog aus dem Einbruch bei kernel.org 2011 die Regel, Vertrauen gehöre zu den Entwicklern und nie zur Infrastruktur, die den Code hostet; PGP-Schlüssel sichern dort die Integrität des Kernels [29]. Bei Debian ist die Identität eines Entwicklers sein OpenPGP-Schlüssel im Debian-Schlüsselbund [30]. Die Paketverwaltung APT prüft Signaturen seit Version 2.9.19 (Dezember 2024) auf unterstützten Plattformen mit Sequoia statt GnuPG [31]. Wie viele Commits oder Pakete weltweit signiert sind, dazu fand sich keine Zahl.

Als Web-Login gibt es einzelne Dienste. Bei IndieLogin.com signiert der Nutzer eine kurze Challenge; der öffentliche Schlüssel liegt auf der eigenen Website, die Identität ist die eigene Domain [23]. Passbolt nennt sein bisheriges Protokoll GpgAuth „legacy“ und will es durch einen Ablauf mit JWT ersetzen. Abgelöst wird das Protokoll, nicht OpenPGP: Auch im neuen Ablauf signiert der Client eine Challenge mit Domain, Token und Ablaufzeit mit seinem PGP-Schlüssel [17]. Keyoxide belegt über OpenPGP-Schlüssel ohne zentrale Plattform, dass Konten auf verschiedenen Diensten derselben Person gehören [25]. Keybase, früher der bekannteste Dienst dafür, wurde am 07.05.2020 von Zoom übernommen [26].

Die Lernseite pgp.stevennoack.de lässt den Entschlüsselungs-Login ausprobieren

Die Lernseite pgp.stevennoack.de bildet den Ablauf nach Darknet-Vorbild nach: registrieren ohne E-Mail und ohne Passwort, anmelden durch Entschlüsseln einer Challenge. Im Einsteigerpfad erzeugt der Browser das Schlüsselpaar mit der Bibliothek OpenPGP.js, der private Schlüssel wird als Datei heruntergeladen, der Server speichert nur den öffentlichen Schlüssel. Im Profipfad fügt der Nutzer einen vorhandenen öffentlichen Schlüssel ein, etwa aus Gpg4win/Kleopatra, und entschlüsselt die Challenge im eigenen Programm. Registrierungen verfallen nach 30 Tagen [34].

Seit dem 13.10.2026 gibt es zusätzlich einen Weg ganz ohne JavaScript unter pgp.stevennoack.de/ohne-js/, nur mit Formularen, also auch im Tor Browser auf der Stufe „Am sichersten“. Die Challenge enthält seitdem Domain und Ablaufzeit im verschlüsselten Klartext („Anmeldung bei: pgp.stevennoack.de“, „Gültig bis: …“). Im Weg mit JavaScript vergleicht der Browser diese Zeile mit der aufgerufenen Adresse und bricht bei Abweichung ab; der Server weist eingefügten Text mit fremder Domain zurück. Damit greift die Schwäche aus der Studie von Güldenring und Roth hier nur noch, wenn ein Mensch nur den nackten Code abtippt und die Adresszeile nicht liest. Beide Wege wurden am 13.10.2026 live durchgespielt, der Weg ohne JavaScript mit GnuPG auf der Kommandozeile.

Offenlegung: Die Lernseite gehört zu dieser Webseite.

Quellen

Alle Abrufe am 13.10.2026.

• [1] VICE/Motherboard, „Some Dark Web Markets Have Better User Security than Gmail, Instagram“, 2016: https://www.vice.com/en/article/some-dark-web-markets-have-better-user-security-than-gmail-instagram/ • [2] Wang et al., „Secure in the dark? An in-depth analysis of dark web markets' security“, International Journal of Information Security, 03.04.2025: https://link.springer.com/article/10.1007/s10207-025-01015-1 • [3] Güldenring, Roth, „Protecting Onion Service Users Against Phishing“, arXiv:2408.07787v1, 14.08.2024: https://arxiv.org/html/2408.07787v1 • [4] Dwyer et al., „How darknet market users learned to worry more and love PGP“, arXiv:2203.08557, 16.03.2022: https://arxiv.org/abs/2203.08557 • [5] Tai, Soska, Christin, „Adversarial Matching of Dark Net Market Vendor Accounts“, KDD '19: http://www.contrib.andrew.cmu.edu/~nicolasc/publications/Tai-KDD19.pdf • [6] OWASP Forgot Password Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html • [7] Auth.js, E-Mail-Anmeldung: https://authjs.dev/getting-started/authentication/email • [8] NIST SP 800-63B-4, August 2025: https://pages.nist.gov/800-63-4/sp800-63b.html • [9] Google-Hilfe, „Your account is disabled“: https://support.google.com/accounts/answer/40695?hl=en • [10] New York Times, Kashmir Hill, 21.08.2022: https://www.nytimes.com/2022/08/21/technology/google-surveillance-toddler-photo.html • [11] Have I Been Pwned, öffentliche API (Summe des Felds PwnCount): https://haveibeenpwned.com/api/v3/breaches • [12] W3C, Web Authentication Level 3, Empfehlung vom 25.08.2026: https://www.w3.org/TR/webauthn-3/ • [13] FIDO Alliance, Passkeys: https://fidoalliance.org/passkeys/ • [14] Apple, Sicherheit von Passkeys: https://support.apple.com/en-us/102195 • [15] Bitwarden zum Credential Exchange Protocol: https://bitwarden.com/blog/security-vendors-join-forces-to-make-passkeys-more-portable-for-everyone/ und FIDO-Spezifikationen: https://fidoalliance.org/specifications-credential-exchange-specifications/ • [16] Nostr NIP-01, NIP-07, NIP-42, NIP-46, NIP-98: https://github.com/nostr-protocol/nips • [17] Passbolt, Authentication und „How Passbolt Secures Your Data“: https://www.passbolt.com/docs/development/authentication/ und https://www.passbolt.com/docs/user/introduction/how-passbolt-secures-your-data/ • [18] Wueppelmann, „PGP Auth: Using Public Key Encryption for Authentication on the Web“, Masterarbeit, Carleton University, 2015: https://chorus.scs.carleton.ca/wp-content/papercite-data/pdf/wueppelmann2015thesis-carleton.pdf • [19] Latacora, „The PGP Problem“, 16.07.2019: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ • [20] Robert J. Hansen, „Why Some Criticisms Matters More Than Others“, GnuPG-Blog, im Text datiert 30.03.2026, in der Adresse 20.03.2026: https://www.gnupg.org/blog/20260320-some-criticism-matter.html • [21] Yubico, PGP: https://developers.yubico.com/PGP/ • [22] RFC 9580, OpenPGP, Juli 2024: https://www.rfc-editor.org/rfc/rfc9580.html • [23] IndieLogin.com, PGP-Einrichtung und Statistik: https://indielogin.com/setup/pgp und https://indielogin.com/stats • [24] AVideo Wiki, „PGP 2FA Login“: https://github.com/WWBN/AVideo/wiki/PGP-2FA-Login • [25] Keyoxide, Dokumentation: https://docs.keyoxide.org/wiki/keyoxide/ • [26] Keybase, „Keybase joins Zoom“, 07.05.2020: https://keybase.io/blog/keybase-joins-zoom • [27] RFC 4252, SSH Authentication Protocol, 2006: https://www.rfc-editor.org/rfc/rfc4252.txt • [28] GnuPG, Agent-Optionen: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html • [29] Linux Kernel, Maintainer PGP Guide: https://docs.kernel.org/process/maintainer-pgp-guide.html • [30] Debian Keyring: https://keyring.debian.org/ • [31] APT-Changelog (Einträge 23.12.2024 und 25.04.2025): https://salsa.debian.org/apt-team/apt/-/raw/main/debian/changelog • [32] GitHub, Commit-Signaturen: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification • [33] LibrePGP: https://librepgp.org/ • [34] Lernseite pgp.stevennoack.de und Quellcode, geprüft am 13.10.2026: https://pgp.stevennoack.de