1. Unnötiges Risiko
Webtracking gibt es schon seit den Anfängen des Internets. Dabei wird das Ziel verfolgt, das Verhalten eines Besuchers auf einer Webseite zu erfassen und anschließend seine Verhaltensweisen zu analysieren. Allerdings führen Webseitenbetreiber dieses Tracking meist nicht mehr selbst durch, sondern beauftragen Drittanbieter mit der Sammlung und Auswertung der Besucherinformationen.
Das Outsourcing dieser Besucheranalyse an Drittanbieter macht es allerdings wiederum notwendig, dass ein Webseitenbetreiber externe Ressourcen einbindet, die dann bspw. über Web-Bugs oder JavaScript das Besucherverhalten erfassen und analysieren. Vielfach wird allerdings dem Risiko, dass mit der Einbindung externen Ressourcen einhergeht, nicht genügend Beachtung geschenkt.
Gerade in sensiblen Bereichen, wie dem Online-Banking, sollte man besonders kritisch sein und die Einbindung von externen Ressourcen hinterfragen. Leider schrecken viele Banken nämlich nicht davor zurück, ihre Kunden durch Drittanbieter tracken zu lassen und setzen sie damit einem unkalkulierbaren Risiko für Sicherheit und Privatsphäre aus.
Im vorliegenden Beitrag möchte ich sowohl Bankkunden, als auch die Verantwortlichen (Banken) für diese Problematik sensibilisieren.
2. Das Problem: Einbinden von Drittquellen
Beim Besuch einer Webseite lädt ein Browser unterschiedliche Ressourcen wie Texte, Bilder oder Videos und stellt diese dar. Diese Ressourcen werden vom Webseitenbetreiber meist direkt in die Seite eingebunden und direkt über seine Webseite ausgeliefert. Bei der Wahl der Quelle für diese Ressourcen müssen Webseitenbetreiber diese Ressourcen nicht zwingend auf ihrem Server hosten und an den Browser des Nutzers ausliefern.
Vielmehr ist es ihnen auch möglich, Ressourcen aus anderen Quellen mit einzubinden. Zu diesen fremd eingebundenen Ressourcen zählen neben Bildern oder Videos häufig auch JavaScript, Schriftarten oder Social-Media-Angebote. Ruft ein Besucher eine Webseite nun auf, ist es für ihn zunächst nicht ersichtlich, welche externen Ressourcen ein Webseitenbetreiber alles eingebunden hat und welche von seinem Server stammen. Tools wie Webbkoll können diese »Vertrauensbeziehungen« zu Drittanbietern sichtbar machen.
Der Kuketz-Blog ist spendenfinanziert!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Drittanbieter: Eine Vertrauensbeziehung
Mit jeder Ressource die ein Webseitenbetreiber einbindet, geht er eine Vertrauensbeziehung mit der jeweiligen Quelle bzw. Domain ein. Das bedeutet wiederum auch, dass die eigentliche Kontrolle über die ausgelieferte Ressource allein beim Drittanbieter liegt. Wird der Drittanbieter allerdings in irgendeiner Form kompromittiert bzw. gehackt, kann das unter Umständen dazu führen, dass der Angreifer die auszuliefernde Ressource gegebenenfalls modifiziert und dass beispielsweise statt eines schadlosen, ein schadhafter JavaScript-Code an den Besucher einer Webseite ausgeliefert wird.
Angenommen der Anbieter, der mit der Auswertung der Besucherinformationen beauftragt wurde, wird kompromittiert. Die Folge: Angreifer verändern den JavaScript-Code und fügen bösartige Code-Zeilen hinzu. Sobald ein Besucher die Webseite aufruft wird der schadhafte JavaScript-Code vom Drittanbieter (code.etracker.com) in den Kontext der eigentlich vertrauenswürdigen (Banken-)Webseite eingebunden und anschließend vom Browser ausgeführt.
Eine böswillige Veränderung von JavaScript-Code kann unter anderem dazu missbraucht werden, um Cookies aus dem Kontext einer Webseite zu stehlen oder die Login-Daten (Benutzernamen & Passwort) abzugreifen. Für diesen Vorgang benötigt ein Angreifer noch nicht einmal Zugang zur Webseite des Betreibers, sondern einzig und alleine zum JavaScript, das er entweder selbst kontrolliert oder entsprechend auf dem Server des Drittanbieters modifiziert hat. Fatal an dieser ganzen Thematik ist, dass der Webseitenbetreiber praktisch keine Chance hat, von dieser Veränderung etwas mitzubekommen. Vielmehr muss er dem Anbieter blind vertrauen und sich damit auch darüber im Klaren sein, dass er durch die Einbindung von externem Code zum einen seinen Besuchern und damit auch letzten Endes sich selber extrem schaden kann. Mittlerweile steht mit »Subresource Integrity« eine Technologie bereit, die die Integrität von JavaScripten sicherstellt, die über Drittseiten eingebunden werden. Darüber ließen sich nachträgliche und auch bösartige Veränderungen an JavaScript-Code erkennen. Allerdings wird diese Technik noch nahezu von keinem Webseitenbetreiber bzw. Drittanbieter verwendet.
Reine Theorie? Mitnichten – es gab schon diverse Fälle, wo genau dieses Szenario eingetreten ist. Ein Sicherheitsvorfall auf der Webseite des Finanzdienstleistungsunternehmens Equifax führt einem bspw. vor Augen, welche negativen Auswirkungen mit der Einbindung externen JavaScript-Codes einhergehen kann. Über die Webseite bzw. das eingebundene JavaScript des Drittanbieters wurde Adware ausgeliefert, mit der sich eine bis dato unbekannte Anzahl von Nutzern infizierte.
2.2 Weshalb Drittanbieter eingebunden werden
Das Einbinden externer Dienste auf Webseiten verfolgt meist unterschiedliche Ziele. Für viele Webseitenbetreiber ist es schlichtweg bequem, eine JavaScript-Bibliothek von einer externen Quelle einzubetten, ohne sich die Mühe zu machen, die für die Funktionalität der Webseite benötigen Ressourcen selbst zu hosten.
Der Hauptgrund, weshalb Ressourcen von Drittanbietern wie Google, Facebook, Adnexus, Oracle und Co. in den Kontext einer Webseite eingebunden werden, lässt sich grob auf zwei Anwendungszwecke reduzieren:
- Tracking: Beim Tracking wird das Ziel verfolgt, das Verhalten eines Besuchers auf einer Webseite zu erfassen und anschließend seine Verhaltensweisen zu analysieren. Die daraus gewonnenen Erkenntnisse werden meist zur Optimierung und Kontrolle einer Webseite eingesetzt bzw. liefern insbesondere im elektronischen Handel wichtige Informationen
- Werbung: In den meisten Fällen wird die Werbung über einen Dienstleister ausgeliefert, der vom Seitenbetreiber in den unterschiedlichsten Formen, wie Banner, Textwerbung oder Pop-up Fenster, in die Webseite eingebunden wird. Insbesondere Nachrichtenseiten, Blogs oder auch andere kostenfreie Dienste finanzieren darüber einen Großteil ihres Angebots.
Daneben existieren weitere Anwendungsszenarien, weshalb Webseitenbetreiber externe Ressourcen einbinden. Diese stehen allerdings nicht im Fokus des vorliegenden Beitrags und werden nicht näher beleuchtet. Anbei einige Beispiele:
- Schriftarten (bspw. fonts.google.com)
- Newsletter Services
- Maps bzw. Kartenmaterial
- Soziale Netzwerke / Social-Sharing-Buttons
- […]
3. Die Folge: Ein Sicherheits- und Datenschutzrisiko
Durch das unreflektierte Einbinden von externen Ressourcen bzw. Drittanbietern entstehen Risiken, die für die Rechte und Freiheiten eines Webseitenbesuchers ungeahnte Konsequenzen haben können.
Im Folgenden möchte ich auf die Risiken eingehen, die bei der Einbindung von Werbung und Trackern für die Sicherheit und den Datenschutz der Webseitenbesucher einhergehen.
3.1 Sicherheitsrisiko am Beispiel von Werbung
Die Darstellung von Werbung ist nicht nur hinsichtlich der Privatsphäre eines Besuchers bedenklich, sondern insbesondere bezüglich seiner Sicherheit. Werbenetzwerke haben immer mal wieder mit einem Problem zu kämpfen, das sich in den letzten Jahren massiv ausgebreitet hat. Mittels schadhafter Online-Werbung, sogenanntes Malvertising, werden zunehmend Sicherheitslücken in Browsern, Addons usw. ausgenutzt, die unter anderem dazu führen, dass Rechner der Besucher vollständig gekapert werden können.
Gelingt es dem Angreifer, eine entsprechende Schwachstelle im Browser bzw. in der vom Browser verwendeten Software auszunutzen, wird zusätzlicher Schadcode geladen, der unter anderem die Festplatte verschlüsseln oder sensible Zugangsdaten von den infizierten Rechnern ausspähen kann.
Wie einige Schlagzeilen aus der einschlägigen Berichterstattung zeigen, gelingt es Angreifern zunehmend, die Sicherheitsmaßnahmen von Werbedienstleistern -auch Google- zu umgehen und ihre Schadsoftware auszuliefern:
- 22.09.2014: Doubleclick und Zedo lieferten virenverseuchte Werbung aus
- 15.09.2015: Malware-Angriff aus der Werbung
- 16.03.2016: US-Nutzer mit Angler-Exploit-Kit und Ransomware infiziert
- 04.11.2016: Malware für Mac-Nutzer per Google-Anzeige verteilt
- 07.12.2016: Forscher stoppen monatelange Malvertising-Kampagne
Insbesondere wenn es gelingt, Schadcode in den Anzeigen von großen Werbenetzwerken, wie DoubleClick (Google), unterzubringen, vervielfacht dieses die Wahrscheinlichkeit einer erfolgreichen Infektion entsprechender Browser/Rechner erheblich. Die Auslieferung von Werbung bedingt wie dargestellt meist die Einbindung vorgefertigter JavaScript-Codes, die der Seitenbetreiber vom Werbedienstanbieter bereitgestellt bekommt und an geeigneter Stelle in seine Webseite integrieren muss.
3.2 Datenschutzrisiko am Beispiel von Trackern
Ursprünglich war die Tracking-Technik vor allem dazu gedacht, einem Webseitenbetreiber zu ermöglichen, die Aktionen eines Besuchers zu analysieren, um daraus Erkenntnisse zu gewinnen, wie er seine Webseite (weiter) optimieren/verbessern kann. Doch die Tracking-Techniken haben sich immer mehr zu einem perfiden Werkzeug entwickelt, mit dem man das Surfverhalten von Nutzern auch jenseits der einzelnen Webseite, praktisch durch das ganze WWW nachverfolgen kann. Diese Problematik des seitenübergreifenden Trackings hat sich insbesondere dadurch verschärft, dass Webseitenbetreiber die Erfassung und Auswertung ihrer Besucher gar nicht mehr selbst durchführen (wollen), sondern diesbezüglich zunehmend auf externe Dienstleister wie Google zurückgreifen, die ihnen diese Arbeit abnehmen.
Das Outsourcing dieser Besucheranalyse zu Drittanbietern macht es allerdings wiederum notwendig, dass ein Webseitenbetreiber externe Ressourcen einbindet, die dann z. B. über Web-Bugs oder JavaScript das Besucherverhalten erfassen und analysieren. Die Einbindung von Google Analytics ist für den Webseitenbetreiber meist bequem und mit wenig Aufwand verbunden (lässt sich mit ein paar Klicks durchführen), weshalb sich diese Praxis allgemein durchgesetzt hat.
Ein weiterer Vorteil von Google Analytics stellt die vermeintlich meist kostenlose Nutzungsmöglichkeit für einen Webseitenbetreiber dar. Dieser muss lediglich – als Gegenleistung – mit den Daten seiner Besucher »bezahlen«.
Durch die Einbindung externer Dienstleister in seine Webseite geht ein Webseitenbetreiber demnach eine Vertrauensbeziehung ein, ohne sich womöglich mit der daraus resultierenden Tracking-Problematik bzw. der Aufzeichnung sensibler Informationen durch Dritte ausreichend auseinandergesetzt zu haben.
Letztendlich sollte man sich nochmals vor Augen führen, dass beispielsweise bei einem Besuch auf einem News-Portal durchschnittlich ca. 45 externe Dienstleister das Surfverhalten »tracken« und gerade große Anbieter wie Google dadurch in die Lage versetzt werden, einen Nutzer nahezu lückenlos über das Internet zu verfolgen – ganz gleich ob die IP-Adresse vor der Übermittlung »anonymisiert« wird. In der Studie (Cross-)Browser Fingerprinting via OS and Hardware Level Features wird aufgezeigt, dass sich über Browser-Merkmale (Bildschirmauflösung, Farbtiefe, etwaige im Browser installierte Plugins oder Schriftarten) 99,24 % der Besucher wiedererkennen lassen. Es ist also auch ohne die Verwendung von Cookies oder der vollständigen Übermittlung der IP-Adresse möglich, dass Google das Surfverhalten des Nutzers seitenübergreifend verfolgt / trackt.
4. Banken
Trotz der Risiken für Sicherheit und Privatsphäre schrecken einige Banken nicht davor zurück, beim besonders sensiblen Online-Banking, ihre Kunden durch Drittanbieter tracken zu lassen – oder sogar Werbung einzubinden!
Im Folgenden sind Onlinebanking-Portale von einzelnen Banken aufgelistet, die mit dem Analyse-Werkzeug Webbkoll auf die Einbindung von Drittanbieter-Ressourcen geprüft wurden. Die Prüfung erfolgte am 25.01.2018 und umfasst lediglich die Login-Seite zum Online-Banking. Ob und wie Kunden der jeweiligen Bank nach erfolgtem Login / Logout getrackt werden, ist nicht Bestandteil der Betrachtung.
Da nur sieben Banken geprüft wurden, ist das Ergebnis natürlich alles andere als repräsentativ. Es bleibt allerdings festzuhalten: Jede getestete Bank gibt Daten an Drittanbieter weiter.
4.1 Comdirect
- Login-URL: https://kunde.comdirect.de/lp/wt/login
- Drittanbieter: 1
- Adform
- Drittanbieter-Ressourcen: 2
- track.adform.net (Tracking: Grafik)
- track.adform.net (Tracking: Grafik)
4.2 Commerzbank
- Login-URL: https://kunden.commerzbank.de/lp/login?pk
- Drittanbieter: 2
- Google Analytics
- Google Tag Manager
- Drittanbieter-Ressourcen: 4
- 3x www.google-analytics.com (Tracking: JavaScript)
- www.googletagmanager.com (Tracking: JavaScript)
4.3 DKB
- Login-URL: https://www.dkb.de/banking
- Drittanbieter: 1
- Webtrekk
- Drittanbieter-Ressourcen: 1
- dkb01.webtrekk.net (Tracking: Grafik)
4.4 N26
- Login-URL: https://my.n26.com/
- Drittanbieter: 4
- Google Tag Manager
- TrackJS
- Cloudfront (Ressource gehört zu TrackJS)
- N26 (Technik)
- Drittanbieter-Ressourcen: 6
- www.googletagmanager.com (Tracking: JavaScript)
- usage.trackjs.com (Tracking: Grafik)
- d2zah9y47r7bi2.cloudfront.net (Tracking: JavaScript)
- 3 x api.tech26.de
4.5 Targo Bank
- Login-URL: https://www.targobank.de/de/identification/login.cgi
- Drittanbieter: 6
- Google DoubleClick
- Google Analytics
- Adform
- Google USA
- Google Frankreich
- Google Ad Services
- Drittanbieter-Ressourcen: 23
- www.google-analytics.com (Tracking: JavaScript)
- track.adform.net (Tracking: Grafik)
- www.googleadservices.com (Werbung / Tracking: JavaScript)
- googleads.g.doubleclick.net (Werbung: Grafik)
- […]
4.6 Volkswagen Bank
- Login-URL:https://www.vwfs.de/
- Drittanbieter: 2
- Google Analytics
- Adobe (Web Analytics)
- Drittanbieter-Ressourcen: 4
- ssl.google-analytics.com (Tracking: JavaScript)
- ssl.google-analytics.com (Tracking: Grafik)
- 2x volkswagenbank.d3.sc.omtrdc.net (Tracking: Grafik)
- […]
4.7 MoneYou
- Login-URL: https://www.moneyou.de/PersoenlicheSeite/Login
- Drittanbieter: 4
- Snowplow
- Cloudfront (Ressource gehört zu Snowplow)
- Sitestat
- Relay42 Technologies
- Drittanbieter-Ressourcen: 7
- 2x nl-moneyou-main.collector.snplow.net (Tracking: Grafik)
- dw3ysqqy2t380.cloudfront.net (Tracking: JavaScript)
- 2x nl.sitestat.com (Tracking: Grafik)
- ssl.synovite-scripts.com (Tracking: JavaScript)
- tdn.r42tag.com (Tracking: JavaScript)
5. Ergebnis & Schutz
Die Ergebnisse dieses Tests zeigen, dass alle getesteten Banken Ressourcen von Drittanbietern in den besonders sensiblen Login-Bereich einbinden. In Anbetracht der aufgezeigten Risiken, die mit der Einbindung von Trackern und Werbung einhergehen, ist das Ergebnis alarmierend. Insbesondere vor dem Hintergrund, dass Banken äußerst beliebte Ziele für Betrugs- und Hacking-Versuche sind. Die Aufgabe einer Bank sollte eigentlich darin bestehen, die höchstmögliche Sicherheit zu gewährleisten, anstatt ihre Kunden durch die Einbindung externer Ressourcen einem zusätzlichen Risiko für Sicherheit und Privatsphäre auszusetzen.
5.1 Schutzmaßnahmen
Bis bei den Banken ein Umdenken stattfindet, kann man den betroffenen Bankkunden lediglich raten, ein Browser-Addon wie uBlock Origin zu installieren, um das Tracking und die Auslieferung von Werbung durch Drittanbieter zu verhindern. Fortgeschrittene Nutzer können zusätzlich einen Pi-hole in Betrieb nehmen oder mit dem Browser-Addon uMatrix explizit die Kontrolle über Drittquellen übernehmen. Das Addon könnte man als eine Art Firewall beschreiben, die das Nachladen von Ressourcen wie Skripte, Bilder, Stylesheets, Cookies und mehr erlaubt / blockiert.
Eine weitere Alternative zum herkömmlichen Online-Banking via Browser sind spezielle Clientprogramme, die bspw. über HBCI oder FinTS eine direkte Kommunikation zum Kreditinstitut ermöglichen. Hierbei wird das Tracking auf den Bankenseiten umgangen, da die Kommunikation dann nicht über den Browser erfolgt, sondern über die entsprechenden Clients wie bspw. Hibiscus.
6. Fazit
Insbesondere Unternehmen oder Institutionen, die Dienstleistungen in sensiblen Bereichen anbieten, sollten in der Lage sein, ihren Webauftritt entsprechend sicher und datenschutzfreundlich zu gestalten. Wie der Test zeigt, ist dies allerdings bei einigen Banken nicht der Fall, was nach meiner Auffassung ein Zeichen dafür ist, dass die Verantwortlichen sich mit den technischen und rechtlichen Fragestellungen, die sich im Bereich des sicheren und respektvollen Umgangs mit personenbezogenen Daten ergeben, offenbar nicht auseinandersetzen wollen oder können.
Eine seriöse Bank, die die Sicherheit und die Privatsphäre ihrer Kunden im Blick hat, verzichtet gänzlich auf die Einbindung externer Dienstleister in den Kontext ihrer Webseite – nicht nur beim Login-Bereich für das Online-Banking.
Bildquellen:
Bank: Roundicons from www.flaticon.com is licensed by CC 3.0 BY
Lights: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Das kranke WWW: Stop using Google Web-Services
ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
Firefox: uMatrix – Firefox-Kompendium Teil9
Firefox: NoScript – Firefox-Kompendium Teil5
Firefox-Kompendium: Warum ein JavaScript-Blocker notwendig ist
10 Ergänzungen zu “Wie Banken die Sicherheit und Privatsphäre ihrer Kunden aufs Spiel setzen”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit.
Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Meine Bank(en) tauchen in uBlock-Origin nicht negativ auf.
Mit einer Positivliste, die der ein oder andere Kunde zum Wechsel animiert, könnte man auch ein stärkeres Interesse für das Thema bei den Banken wecken.
Die Hypovereinsbank scheint dort ziemlich sauber zu sein: https://my.hypovereinsbank.de/login?view=/de/login.jsp
Ich bin bewusst bei einer Bank, die keinerlei externe Quellen im Loginbereich einbindet.
Als ich mal bei einer anderen Bank, zu der ich überlegte zu wechseln, angeftagt habe, wurde mir erklärt man setze Schutzmechanismen wie Subresource-Integrity und Content Securitiy Policy ein und das sei alles vollkommen sicher, da der Javascript Code nur zur Analyse und nicht zum Tracking verwendet würde, die Daten bei der Bank bleiben und auch kein von der Bank unauthorisierter Code ausgeführt werden könne.
Da ich kein Experte auf diesem Gebiet bin, kann ich das schwerlich hinterfragen.
Matthias! Wäre schön gewesen, wenn du deine so positiv in Erscheinung tretende Bank oder Sparkasse namentlich erwähnt hättest. Denn das ist sicherlich auch für Mitleser interessant!
Hallo Mike,
mir hat als normaler, jedoch erfahrener User und aufmerksamer Leser deines Blogs vor allem der letzte Teil des Artikels sehr gefallen.
Es wäre gut, wenn es mehr digitale Selbstverteidigungstipps mit Browsererweiterungen oder Prüftools gäbe von dir. Vielleicht auch als Kurzartikel mit Verweisen auf die Fachartikel von dir.
Nicht jeder Anwender hat so tiefe Kenntnisse oder ist beruflich mit Systemschutz vertraut wie du.
Viele Dank für deine Zeit und Arbeit. Wird Zeit für mich, dass ich das honorieren sollte. ;-)
Hallo Mike,
in der von Dir im Artikel verlinkten Studie empfehlen die Autoren zur Milderung des Problems die Verwendung von TOR als auch Virtualisierung. Da TOR gemäß 3-Browser-Konzept für Online-Banking ausgeschlossen ist: Könnte es helfen, für Online-Banking Firefox in einem extra dafür geschaffenen KVM-basiertem Linux-Betriebssystem laufen zu lassen?
Wenn Du dir hierzu schon mal Gedanken gemacht hast, würde mich das sehr interessieren.
Ich habe die DiBa mal getestet, auch dort ist es ziemlich sauber: https://banking.ing-diba.de/app/login
Hallo Mike,
spricht was gegen BBBank in Raum KA?
Kein Tracking in Online-Banking.
PIN bis 20 Zeichen
Direktbank mit Filialen
Keine Kontoführungsgebühr. Natürlich stelle ich mir dann die Frage, womit die Bank die Geschäfte macht.
Ich finde Webseiten auch fürchterlich, die externe JavaScripts einbinden (Manchmal ja 10 und mehr). Das ist mit NoScript in Firefox zum Teil eine richtige Odyssee, bis man alles zwingend notwendige identifiziert und aktiviert hat. Da mach ich die Seite dann auch mal einfach wieder zu, wenn es nicht wichtig ist oder es alternative Anbieter gibt.
Bezüglich meiner Bank (Sparkasse Ansbach: https://www.sparkasse-ansbach.de) ist mir in der Hinsicht noch nie etwas Negatives aufgefallen, was mich sehr freut. Ich habe den Artikel aber mal zum Anlass genommen, einmal etwas genauer hinzusehen:
Untersucht wurden:
* Login
* normales Navigieren auf der Seite
* Überweisung ausfüllen
Die Ergebnisse:
* NoScript meldet: keine externen JavaScripte
* FireBug meldet: nur HTTPS-Anfragen auf *.sparkasse-ansbach.de
Fazit:
Es freut mich, dass die Sparkasse hier scheinbar gute Arbeit leistet. :)
Also ich habe mal Visa.de getestet, da ich eine kostenlose Visacard von der Postbank habe. Sofort auffallend insecure negotiation.
Dann Test bei ssllabs:
There is no support for secure renegotiation. Grade reduced to A-. MORE INFO »
This server does not support Forward Secrecy with the reference browsers. Grade will be capped to B from March 2018. MORE INFO »
This server does not support Authenticated encryption (AEAD) cipher suites. Grade will be capped to B from March 2018. MORE INFO »
Kann man vergessen. Werde ich rasch abmelden. Erstaunlich, dass sie damit noch insgesamt A- erhalten. Für eine Kreditkartenfirma gehört sich kräftig abgestuft.