datenritter blog - SSL/TLS

X.509 ist kaputt. Ende.

nospam@example.com (datenritter) — Sat, 16 Jan 2010 07:09:00 +0100

Ich sag nix mehr zu SSL bzw X.509. Es ist einfach schlimm. Fefe fasst es prima zusammen:

(...) die Israelis (...) bieten einen SSL-Zertifikat-Dienst an, der auch den privaten Schlüssel für dich generiert. How convenient! Und sie haben plausible deniability, weil es auch einen Button zum Hochladen seines eigenen CSR gibt. (...)

Das ist noch besser, als ein schnöder Man-in-the-middle-Angriff, den sowieso jede von den gängigen Browsern anerkannte Zertifikatsautorität spielen kann. So hat man nicht nur gültigen Ersatz, sondern gleich das Original. Ich bin mit den Details des TLS-Verbindungsaufbaus nicht so vertraut, vermute aber mal, dass man damit sogar nachträglich noch den halben aufgezeichneten Datenstrom entschlüsseln kann. Wer das Angebot annimmt, ist selbst schuld.

Wer das technische Verständnis hat, kann sich ja auch die Aufzeichnung von Dan Kaminskys Vortrag auf dem 26C3 ansehen. Er beschäftigt sich mit ein paar Problemchen der X.509-PKI. Und da bleibt kein Stein auf dem anderen.

Ironie: Beim Aufruf von https://events.ccc.de/congress/2009/Fahrplan/events/3658.en.html bekomme ich eine Warnung, weil das Zertifikat des Servers eine MD5-Signatur hat. Arrg!

Mailman-ssls 2.1.12 kleinere Bugfixes

nospam@example.com (datenritter) — Sat, 22 Aug 2009 13:23:35 +0200

Der Mailman-ssls-Patch vom 18.07.2009 enthält Fehler. Mails können unverschlüsselt versandt werden, wenn der Schlüssel des Empfängers ungültig ist, obwohl im das Webinterface "Force" (erzwingen) ausgewählt wurde. Außerdem können Administratoren keine Schlüssel austauschen, beim Austragen eines Mitglieds wird der alte Schlüssel nicht gelöscht. Die ersten beiden Fehler sind mit dem folgenden Patch gegen das hier verlinkte Sourcecode-Paket leicht zu beheben:

"Mailman-ssls 2.1.12 kleinere Bugfixes" vollständig lesen

Mailman-ssls 2.1.12 Sourcecode

nospam@example.com (datenritter) — Mon, 27 Jul 2009 15:39:00 +0200

In diesem Eintrag zu Mailman-ssls ist der gepatchte Code in Version 2.1.11 verlinkt.
Hier nun die neue Version: mailman-ssls-2.1.12.tar.bz2 herunterladen.

Und noch zwei Ergänzungen:

• Ich würde beim configure-Durchlauf noch --with-mail-gid=nogroup anhängen, um Ausführungsproblemen vorzubeugen.

• Unbedingt beachten: Nur die englischen Templates der Weboberfläche wurden gepatcht. Die deutsche Oberfläche erlaubt es nicht, öffentliche Schlüssel der Listenteilnehmer einzutragen, und Mailman-ssls treibt Admins, die es auf anderen Wegen versuchen, in den Wahnsinn.

verschlüsselte Mailinglisten mit Mailman-ssls

nospam@example.com (datenritter) — Wed, 15 Apr 2009 16:24:00 +0200

Für verschlüsselte Mailinglisten gibt es verschiedene Ansätze. Leicht ist das Leben, wenn man Mailman-ssls einsetzt. Die erweiterte Version kann all das, was die verbreitete Mailingslistensoftware Mailman auch kann, beherrscht zusätzlich aber diverse Verschlüsselungsfeatures.

Mails an die Liste werden nur noch mit dem Listenschlüssel verschlüsselt, Mailman-ssls entschlüsselt die Mails und verschlüsselt sie dann wieder für jeden Abonnenten einzeln. Nicht verschlüsselte Mails können abgelehnt werden, Empfänger ohne Schlüssel bekommen keine Kopie. Natürlich müssen die öffentlichen Schlüssel der Empfänger dem Server zur Verfügung stehen. Mailman-ssls hat dafür eine Verwaltungsfunktion.

Der große Vorteil von Mailman-ssls ist, dass die Listenteilnehmer nicht die Schlüssel aller anderen haben müssen oder gar selbst in ihren Mailprogrammen Listen pflegen. Den Komfortgewinn bezahlt man mit ein wenig Zentralismus, was auch ein Nachteil ist, denn der Server muss unbedingt absolut sicher sein, sonst könnten alle Listenmails offengelegt werden. Das heißt, er muss vor Hackerangriffen, aber auch vor physikalischem Zugriff sicher sein. Wie so oft läuft das schnell auf die Frage hinaus, ob man seinem Hoster vertraut, doch dies soll hier nicht diskutiert werden.

Erhalten bleibt auf jeden Fall der Vorteil, dass Mails auf der eigenen Festplatte verschlüsselt abgelegt bleiben, Angriffe gegen einzelne Teilnehmer einer Cryptoliste sind also nicht erfolgversprechender als sonst auch. Mailman-ssls führt aus Sicherheitsgründen standardmäßig kein Archiv und beherrscht OpenPGP-Schlüssel genauso wie X.509-Zertifikate.

Leider hat sich die Einrichtung auf einem Debian-System als etwas schwierig erwiesen, den weiten Weg zum Ziel fasse ich in diesem HowTo zusammen.
"verschlüsselte Mailinglisten mit Mailman-ssls" vollständig lesen

Sparkasse zeigt neuen Fingerprint rechtzeitig

nospam@example.com (datenritter) — Mon, 03 Nov 2008 08:52:00 +0100

Die Förde-Sparkasse verteilt nicht nur Server-Fingerprints auf Papier, sie zeigt auch rechtzeitig die neuen Fingerprints auf der Webseite an:

Der Ihnen bekannte Fingerabdruck (Fingerprint) verliert demnächst seine Gültigkeit. Damit Sie auch weiterhin die Zertifikatsprüfung durchführen können, teilen wir Ihnen nachfolgend den zukünftig gültigen Fingerabdruck mit. Bitte drucken Sie sich diesen aus.

Das ist wirklich vorbildlich.

Zertifikatsautoritäten sind Angriffsvektoren

nospam@example.com (datenritter) — Tue, 30 Sep 2008 21:37:00 +0200

Das Problem mit den ePässen ist offenbar, dass die Terminals selbstsignierte Daten akzeptieren. (Siehe auch: heise-Meldung.) Das lässt sich leicht ändern, in dem man Signaturen zwingend verlangt.

Doch der Beitrag über den schon erwähnten Hack des elektronischen Personalausweises, erklärt sehr prägnant, warum die Zertifikatsautoritäten einer Publik-Key-Infrastruktur (PKI) selbst ein ernsthaftes Problem sein können. Die Kritik lässt sich auf andere Einsatzfelder der PKI anwenden, zum Beispiel bei SSL-geschützten Webseiten:

Using a Certification Authority (CA) could solve the attack but at the same time
introduces a new set of attack vectors:

1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker.
Single point of failures are not good. Attractive targets are not good.

Das ist die wichtigste Erkenntnis: Die Zertifikatsautorität (CA) ist der "single point of failure" und ein hochwertiges Ziel für einen Angreifer.

Any person with access to the CA key can undetectably fake passports. Direct attacks, virus,
misplacing the key by accident (the UK government is good at this!) or bribery are just a few
ways of getting the CA key.

Ich übersetze mal sinngemäß: Wer auch immer Zugang zum Schlüssel einer CA hat kann unbemerkt Ausweise fälschen. Durch direkte Angriffe, Viren, irrtümliche Preisgabe des Schlüssels oder Bestechung könnte man an den Schlüssel gelangen. Dass gelegentlich USB-Sticks, Festplatten, ja sogar Kameras mit geheimen Daten in Umlauf gelangen, dürfte bekannt sein.

Nun folgen ein Punkt, der zu Diskussionen führt und nicht oberflächlich betrachtet werden darf:

2. The single CA would need to be trusted by all governments. This is not practical as this
means that passports would no longer be a national matter.

Dass es keine multinationale CA geben kann, ist offensichtlich, doch:

3. Multiple CA's would not work either. Any country could use its own CA to create a valid
passport of any other country. (...)

Diese Behauptung ist die am häufigsten kritisierte und gilt vermutlich nur für schlecht aufgesetzte ePass-Terminals. Selbst wenn alle Terminals derart nachlässig sind, wird man dies bald ändern. Doch gilt sie uneingeschränkt für SSL-Zertifikate, z.b. für Webseiten, denn ein Browser kann nicht wissen, welche CAs für meine Bank zuständig sein sollen und welche nicht.

Und für den ePass gilt:

This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.
Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not be detected.

Denn es kommt bei einer Fälschung vielleicht nicht unbedingt darauf an, aus welchem Land der falsche Pass stammt.

Sicher ist:
• Die Pässe sind beschreibbar. Man kann also die Daten einer anderen (z.B. ähnlich aussehenden) Person auf den eigenen Chip schreiben — inklusive der gültigen Signatur.
• Angriffe auf CAs sind außergewöhnlich lohnend.
• Viele CAs sind viele Angriffsmöglichkeiten. Zu viele.
• Rückruflisten helfen nur, wenn die Fälschung überhaupt bemerkt wird. Das ist sehr unwahrscheinlich.

Ich empfehle als Notbehelf für den ePass die Mikrowelle. Sie verhindert wenigstens, dass ein Dritter die eigenen Daten ausliest und verwendet. Für Webseiten gibt es auch weiterhin keine einfache Lösung, außer der händischen Prüfung des Fingerprints.

Debian-OpenSSL-Debakel: Problem auf Layer 8

nospam@example.com (datenritter) — Tue, 10 Jun 2008 14:31:00 +0200

Das kam jetzt natürlich völlig überraschend: Laut einer Meldung im heise-Newsticker und dem zugehörigen Artikel in der c't 13/08 benutzen viele Webshops Server-Zertifikate mit schwachem Schlüssel.

Bei einer Untersuchung von über 4300 gültigen Zertifikaten, die im Browser keine Warnung erzeugten, fand c't, dass etwa jedes dreißigste einen solchen schwachen Schlüssel nutzt. Darunter fanden sich auch Online-Shops, die zum Beispiel zur Eingabe von Kreditkartennummern auffordern.

(...)

Alle von c't befragten CAs erklärten, man könne bei ihnen schwache Zertifikate kostenlos widerrufen und durch neue ersetzen lassen. Doch offenbar machen von dieser Möglichkeit bislang nur wenige Zertifikatseigner Gebrauch.

Die Shop-Betreiber sind vermutlich nicht gerade Spezialisten, was OpenSSL angeht. Die Frage ist, wo sie ihre Zertifikate her haben, und warum sie nicht gewarnt werden. Möglicherweise weil die entsprechenden Dienstleister nicht besonders pflichtbewusst sind, oder das Problem nicht verstanden haben.

Doch selbst ein Widerruf der schwachen Zertifikate schafft das Problem nicht aus der Welt. Denn die meisten aktuellen Browser überprüfen die Widerrufslisten in ihrer Standardkonfiguration nicht. (...) Das Online Certificate Status Protocol (OCSP) (...) ermöglicht den Test einzelner Zertifikate. Allerdings unterstützen das viele CAs noch nicht.

So ist es.

Sparkasse verteilt Server-Fingerprints auf Papier

nospam@example.com (datenritter) — Mon, 09 Jun 2008 16:36:00 +0200

Unglaublich, aber heute habe ich zum ersten Mal gesehen, dass eine Bankkundin, die sich für Online-Banking entschieden hat, von ihrer Bank den Fingerprint ihres OpenSSL-Serverzertifikates ausgehändigt bekam.

Die Förde-Sparkasse druckte diesen auf ein Blatt, welches mit den Worten "wichtige Information" überreicht wurde. Dabei steht er offenbar einmal als MD5- und einmal als SHA-1-Fingerprint darauf, doch derart genaue Angaben, die den Kunden verwirren konnten, hat man sich geschenkt. Einer der beiden müsse stimmen, schreibt die Bank lapidar, und das sei ihr gestattet.

Die Förde-Sparkasse wechselt ihre Zertifikate sogar jährlich und zeigt den neuen Fingerprint auf der Online-Banking-Webseite "in einem geschützten Dokument" an. Eine Anleitung zur Überprüfung gibt es auch.

Ob die Sparkassen das schon länger, oder erst seit dem Debian-OpenSSL-Debakel machen, weiß ich nicht, auf jeden Fall ist mir aber von anderen Banken nichts vergleichbares bekannt.

Die Überprüfung des Fingerprints schützt vor Man-In-The-Middle-Angriffen und sogar gegen Unterwanderung der ohnehin zweifelhaften Public-Key-Infrastruktur durch Geheimdienste und ~~andere~~ Kriminelle.

Damit und durch die Aushändigung eines TAN-Blockes gleich in der Filiale hat ausgerechnet die früher(?) als träge und unflexibel geltende ehemalige "Beamtenbank" ihre Konkurrenten in puncto Sicherheit und Komfort mit einem Satz überholt.

Liebe Sparkasse, willkommen in der Gegenwart!

neue erschreckende Fakten zum Debian-OpenSSL-Debakel

nospam@example.com (datenritter) — Tue, 27 May 2008 21:35:00 +0200

Die Angriffsmöglichkeit durch alte Zertifikate hat sich bestätigt. Laut einem Artikel bei heise Security bestehen zudem die Möglichkeit, dass die Systeme, die mit schwachen Schlüsseln ausgestattet waren, bereits früher angegriffen bzw. belauscht wurden.

Es ist schon übel, dass der heise-Newsticker vorgestern nur am Rande in WWW, der "Wochenschau von Hal Faber" über die bestehende Angriffsmöglichkeit durch das OpenSSL-Debakel berichtete:

Es gibt Leute, die viel davon verstehen und die erklären können, wie selbst unsere Selbsteintreibungs-Software ELSTER davon betroffen ist, dass Revocation Lists für Zertifikate nicht funktionieren: Skalierender Schlüsselrückruf ist ein ungelöstes Problem.

Die von mir hervorgehobene Formulierung suggeriert, dass das schon das Ende der Gefahrenstange sei. Das ist nicht der Fall, es kann auch Online-Banking-Webseiten oder andere sensible Bereiche treffen. Nach einem Hinweis antwortete mir Jürgen Kuri, er werde die Leute bei heise Security noch einmal darauf hinweisen.

Heute erschien dann die Meldung "Tausende deutsche Server laden zum Einbruch ein". Dort wird berichtet, dass viele ihre SSH-Schlüssel noch nicht ausgetauscht haben, Provider ihre Kunden nicht benachrichtigen:

Kurze Stichproben von heise Security enthüllten Erschreckendes: In den Netzen von Root-Server-Providern verwendeten von 1938 erreichbaren SSH-Servern 114 bekanntermaßen schwache Schlüssel – das sind immerhin rund fünf Prozent.

Das ist schlimm, aber wartet, es kommt schlimmer.

Man hat sich bei heise Security auch die Mühe gemacht, einen interessanten Artikel über die verschiedenen Gefahren zu schreiben — leider steht zu befürchten, dass den schon aufgrund der Länge kaum jemand liest. Das ist schade, denn auf Seite drei steht der erschreckende Sachverhalt, vor dem ich warnte, in einem Absatz zusammengefasst:

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings seine Opfern per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite umzudirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Und tatsächlich: Alexander Klink berichtet auf der Mailingliste full disclosure, er habe eine Bank ausgemacht, deren altes Zertifikat schwach war. Das Zertifikat ist noch etwa 3 Jahre gültig - so lange sind Man-In-The-Middle-Attacken auf diese Bank möglich.

Als wäre das nicht genug, erklärt der Artikel auch noch, dass aufgezeichnete verschlüsselte Verbindungen nun nachträglich entschlüsselt werden könnten. Es ist durchaus davon auszugehen, dass immer dann, wenn sensible Daten abgegriffen werden sollten, auch verschlüsselte Verbindungen auf Vorrat aufgezeichnet wurden, gerade im Bereich Industriespionage dürfte das üblich sein.

Doch der wahre Schrecken lauert auf Seite fünf:

Wer immer sich in den vergangenen 20 Monaten die Mühe gemacht hat, eine Datenbank mit (...) öffentlichen Schlüsseln zu pflegen, konnte vermutlich ungefähr ab Oktober 2006 die erstaunliche Beobachtung machen, dass in dieser Datenbank Kollisionen auftreten, wo eigentlich keine passieren dürften. Aufgrund des Geburtstagsparadoxons genügen schon 500 schwache Schlüssel gleicher Länge, um unter ihnen mit rund 95-prozentiger Wahrscheinlichkeit ein Duplikat zu finden. Vom Entdecken eines solchen Duplikats ist es nur noch ein kleiner Schritt, um über den ungefähren Zeitpunkt und den Kontext der betroffenen Schlüssel auf das Debian-Betriebssystem zurückzuschließen und die in dem Zeitraum vorgenommenen Änderungen am Quellcode der kryptographisch relevanten Programmpakete zu untersuchen.

Das ist DESASTRÖS. Denn es ist mehr als wahrscheinlich, dass Kriminelle, Geheimdienste, vielleicht auch andere Organisationen Schlüssel gesammelt und das Problem bereits vor langer Zeit bemerkt und für Einbrüche und Lauschaktionen genutzt haben.

gefährliche Angriffsmöglichkeit durch das OpenSSL-Debakel

nospam@example.com (datenritter) — Sun, 25 May 2008 21:15:00 +0200

Felix von Leitner schreibt in seinem Blog über eine wirklich gefährliche Angriffsmöglichkeit, die sich aus dem OpenSSL-Debakel ergibt. Alle Verbindungen zu Servern, die ein "schlechtes" SSL-Zertifikat hatten, sind wahrscheinlich immer noch verwundbar. Felix berichtet, dass dies bei einem Server von Akamai der Fall ist, und über Akamai werden Daten für das Steuerprogramm ELSTER übermittelt.

Wie es funktioniert

Die Angreiferin, nennen wir sie Carol, ruft Daten von einer Webseite ab, deren URL mit https beginnt, also über eine SSL-verschlüsselte Verbindung — z.B. beim Online-Banking. Sie erhält dabei das Zertifikat der Webservers, welches sie speichert. Dieses Zertifikat und der geheime Schlüssel dazu sind nun aber mit der kaputten Version von OpenSSL erzeugt worden.

Mit dem Zertifikat und dem enthaltenen öffentlichen Schlüssel alleine kann Carol nichts anfangen, es ist ganz normal, dass man diese übermittelt bekommt. Wichtig ist allerdings, dass das Zertifikat von einer Zertifikatsautorität (CA) signiert wurde, wodurch die Echtheit sozusagen "offiziell" beglaubigt ist.

Der geheime Schlüssel ist außerdem dank des OpenSSL-Fehlers leicht ermittelbar — Carol erzeugt alle möglichen geheimen Schlüssel einfach selbst und prüft, welcher zu dem öffentlichen Schlüssel des Servers passt.

Nun hat Carol also sowohl den geheimen Schlüssel, den eigentlich nur der Server kennen sollte, als auch ein "von offizieller Stelle" signiertes Zertifikat.

Die Zertifikate der "offiziellen Stellen", also der CAs sind in jedem Webrowser vorinstalliert, das heißt jeder Webbrowser erkennt auch das Zertifikat ohne weitere Prüfung oder Abfrage als gültig an, obwohl es unsicher ist:

CA-Zertifikate bescheinigen die Gültigkeit der Zertifikate von Servern, Software-Herstellern (für Applets etc.) und Mail-Benutzern.

Natürlich haben die Betreiber die verwundbaren Zertifikate schon ausgetauscht. Aber Carol war schnell, und hat das alte vorher gespeichert, gleich nachdem der OpenSSL-Fehler bekannt wurde. (Zukünftig wird Carol dies automatisieren, ein kleines Programm speichert die Zertifikate während sie im Web surft. Denn vielleicht gibt es nochmal so einen Fehler.)

Zwar überprüft ein Browser das Ablaufdatum, welches unveränderlich im Zertifikat steht und dieses nach einer bestimmten Zeit automatisch ungültig macht, aber das ist schlichtweg noch nicht erreicht.

Dagegen gibt es natürlich auch einen Schutzmechanismus, nämlich zentrale Stellen, die Listen mit vorzeitig für ungültig erklärten Zertifikaten enthalten, sogenannte CRLs (Certificate Revocation Lists). Doch diese Listen muss der Browser auch abrufen.

Tut er aber nicht:

Die Standard-Einstellung des Browsers Firefox (Iceweasel 2.0.0.14) ist, keine CRLs abzurufen.

Die Standard-Einstellung des Browsers Firefox ist, keine CRLs abzurufen. Das dürfte bei vielen Programmen so sein, und auch E-Mail-Programme, Homebanking-Programme und Programme zur Übermittlung der Steuererklärung benutzen SSL.

Schaltet man die Prüfung ein, so funktioniert sie möglicherweise nicht, was die Funktion einfach nur lästig macht:

Fehlermeldung bei eingeschalteter Gültigkeitsprüfung mittels OCSP.

Mit dem privaten Schlüssel und dem signierten Zertifikat kann Carol nun dem Browser irgendeines Users glaubhaft vormachen, ihr eigener (manipulierter) Server sei der Server, dessen Zertifikat sie "übernommen" hat. Sie kann sich also als Mittels~~mann~~frau in die vermeintlich geschützte Verbindung einklinken, und somit Daten mitlesen, unterdrücken oder gar verändern, also zum Beispiel Schadcode, etwa einen Trojaner, einschleusen.

Man nennt dies eine Man-In-The-Middle-Attacke, kurz MITM. (Oder WITM. Wegen der Gleichberechtigung.)

Der Haken beim PKI-Verfahren

Wie Felix ganz richtig schreibt, ist das ganze Prinzip der PKI, der Echtheitsprüfung durch irgendwelche Zentralstellen, die der User gar nicht kennt, ihnen also auch nicht vertrauen kann, schon allein durch die Zahl der standardmäßig installierten CA-Zertifikate der eigenartigsten CAs höchst zweifelhaft.

Es ist keine Diskriminierung, sondern reine Vernunft, wenn ich sage, dass ich eigentlich nicht möchte, dass die mir völlig unbekannte Stelle "TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş" (Türkei) oder die"NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado" (Ungarn) Zertifikate für gültig erklärt, mit denen mein Browser verschlüsselte, also vermeintlich sichere Verbindungen aufbaut.

Ich muss überhaupt nicht an Geheimdienste denken, ganz normale Kriminelle werden schon ihre Wege finden, die ein oder andere CA für ihre Zwecke zu missbrauchen.

Was tun?

Das einzige, was Server-Betreiber gegen diesen Angriff tun können, ist das alte Zertifikat dadurch unbrauchbar zu machen, dass sie ihre Domain ändern, bis die alten Zertifikate abgelaufen sind. Dumme Sache.

Benutzer müssen bei vielen Webseiten, die keine "offiziell beglaubigten" Zertifikate haben, ohnehin selbst entscheiden, ob sie das Server-Zertifikat

• nur temporär akzeptieren (es könnte gefälscht sein)
• dauerhaft akzeptieren (sie kommunizieren zumindest immer mit dem selben Server und halten es für unwahrscheinlich, dass Carol dahinter steckt) oder
• verifizieren.

Um diese Entscheidung immer selbst zu fällen, können sie alle CAs, denen sie nicht vertrauen — das werden wohl nahezu alle sein — in den Einstellungen ihrer Software deaktivieren.

Wenn es wichtig ist, und sie das Zertifikat verifizieren müssen, — die Fingerprints überprüfen, in dem sie den Betreiber anrufen.

Bei so etwas wichtigem wie dem Online-Banking oder der Steuerrerklärung z.B. sollte man das unbedingt tun!

Banken und Behörden werden sich natürlich wundern, aber es ist deren Schuld, schließlich schicken die den Kunden zwar stapelweise Papier mit PINs, TANs und iTANs, aber die Fingerprints ihrer Banking-Webseiten und Steuerdatenserver fehlen in den Unterlagen.