Ein Blog-Leser hat mich die Tage auf einen bedenklichen Sachverhalt hingewiesen, der ihm in der Software"WISO Mein Geld" der Buhl Data Service GmbH aufgefallen ist. Wird eine log-Datei erstellt, um im Fehlerfall an das Unternehmen übermittelt zu werden, enthält diese Protokolldatei eine Reihe sensiblere Daten. Rechtlich ist das Ganze wohl in Ordnung, aber ich bin mir nicht sicher, ob sich Nutzer darüber im Klaren sind, dass das konkrete Bankdaten über Konten an Dritte übermittelt werden. Daher stelle ich den Sachverhalt hier im Blog dar.
Anzeige
WISO Mein Geld
Die Buhl Data Service GmbH ist ja Anbieter einer Reihe an Software-Lösungen rund um das Thema Finanzen, die zusammen mit der ZDF-Sendung WISO entwickelt und vermarktet werden. Beim Produkt "WISO Mein Geld" lassen sich diverse Konten (Girokonto, Bausparkonto, Tagesgeld, Kredite etc.) eintragen und verwalten, um den Überblick über die Finanzen zu behalten. Die Software ist multibankenfähig und Nutzer können per Mausklick auch Online-Banking betreiben, Kontoauszüge abrufen und Überweisungen ausführen. Dazu werden die Zugangsdaten zum Online-Banking in der Software hinterlegt, so dass das Programm auf die Konten zugreifen kann. Das Ganze gibt es auch in einer Professional-Ausführung.
Aufzeichnungsprotokoll bei Fehlern
Traten Fehler in einem Produkt auf, legen die meisten Hersteller einer Software dann Protokolle in sogenannten .log-Dateien ab. Dort werden Systeminformationen und ggf. Informationen zur Fehlersituation eingetragen. Die an den Support des Herstellers zu übersendende .log-Datei soll den Entwicklern helfen, die Fehlerursache samt den vorhandenen Bedingungen zur Auslösung des Problems zu verstehen.
Das ist auch in Ordnung, soweit der Nutzer sich über die übertragenen Daten im Klaren ist und der Hersteller sich auf das beschränkt, was zur Fehlerdiagnose erforderlich ist, und zudem auf die datenschutzrechtlichen Sachverhalte hinweist. Ein Blog-Leser ist als Käufer von WISO Mein Geld Professional diesbezüglich aber nicht wirklich zufrieden und hatte mich kürzlich per Mail kontaktiert.
Moin Herr Born,
ich diskutiere da schon seit längerem mit der Firma Buhl rum, dass in den erstellten LOG-Dateien, die man im Falle eines Fehlers an Buhl senden soll, viel mehr persönliche Daten enthalten sind, als angegeben. Auch ist die LOG-Datei nicht verschlüsselt, wie in den Datenschutzhinweisen beschrieben wird.
Der Leser fragte mich, ob ich Interesse hätte, den Sachverhalt im Blog aufzugreifen. Klar habe ich das – und inzwischen kenne ich auch die Position der Firma Buhl Data Service GmbH, bzw. von deren Datenschutzverantwortlichem. Der Punkt "nicht verschlüsselt" ist zwar abgeräumt, aber der Sachverhalt ist durchaus von Interesse.
Anzeige
Umfangreiche und geschwätzige Log-Dateien
Der Leser hatte wohl sein Payback-Konto in WISO Mein Geld eingetragen, um dessen Punktestand zu überwachen. Mir stellt es sich in der Korrespondenz zwischen dem Leser und dem Software-Anbieter so dar, dass dort wohl ein Problem auftauchte und er den Support kontaktierte. In diesem Zusammenhang wurde auch eine .log-Datei übermittelt.
Im Rahmen dieser Übermittlung ist der Leser dann auf eine Reihe Ungereimtheiten gestoßen, die er mit dem Hersteller diskutierte. So wundert sich der Leser über die in der log-Datei übermittelten Daten:
Moin zusammen,
bisher habe ich leider weder von Ihnen, noch von Ihrem Datenschutzbeauftragten ein Feedback bezüglich meine Anfrage vom 01.05.2023 bekommen, warum in der Log-Datei für einen Payback Abruf die (teilweise individuell erstellten) Anmeldedaten für scheinbar alle in Mein Geld hinterlegten Konten enthalten sind. Ob in den verschlüsselten Objekten die Passwörter enthalten sind, ist auch noch ungeklärt.
Mir liegen Auszüge aus log-Dateien vor, die wirklich sehr viele Informationen enthalten. In einer Datei "BCManager2_.log" hat der Nutzer Daten zu den Konten gefunden (nachfolgend nur ein kleiner Ausschnitt), den ich noch anonymisiert habe.
In der Protokolldatei stehen die Daten zu den eingebundenen Konten im Klartext. Sicherheitstechnisch werden Transaktionen auf den Konten zwar über Fin TS abgewickelt. Aber nicht jedem Anwender dürfte es bewusst oder recht sein, dass seine Konteninformationen in der log-Datei stehen und dann an den Software-Anbieter übermittelt werden.
Datenschutzhinweise des Anbieters
Der Anbieter, die Buhl Data Service GmbH, weist korrekterweise auf die datenschutzrechtlichen Belange beim Übertragen der aufgezeichneten .log-Dateien hin. Der Leser hat mir folgenden Screenshot des Datenschutzhinweises zukommen lassen.
Zum Thema, dass die .log-Datei sehr viele persönliche Daten enthält schreibt der Blog-Leser folgendes an den Software-Hersteller:
Sie haben ja inzwischen Ihre Datenschutzrechtlichen Hinweise angepasst, aber es stimmt leider immer noch nicht:
Ich habe vorhin noch einmal den Abruf des Payback-Kontos protokollieren lassen und es sind immer noch viele Daten enthalten, die mit dem Payback Konto überhaupt nichts zu tun haben. Nehmen wir zum Beispiel den Sparda-Netkey. Das ist eine individuell von mir erstellte Zeichenfolge (persönliche Zugangsdaten), zur Anmeldung bei der Sparda-Bank. Diesen finde ich nach wie vor im Klartext in der Datei "BCManager2_.log" Ich hänge die gesamte LOG-Datei von vorhin noch einmal an diese Mail an. Sie ist ja leider nach wie vor nicht verschlüsselt, wie Sie schreiben.
Außerdem frage ich mich, was für den Abruf des Payback-Kontos meine Bildschirmkonfiguration wichtig ist. Diese findet man in der Datei fileinfo_.log [Information zur Log-Datei entfernt].
Die Hauptfrage bleibt aber, warum übermitteln Sie heimlich die in Mein Geld hinterlegten Konten, die nichts mit der protokollierten Abfrage zu tun haben?
Ich würde mich über eine Stellungnahme sehr freuen und wünsche schon mal ein tolles Wochenende!
Die Kritikpunkte des Lesers sind durchaus nachvollziehbar. Es gibt wohl ein Problem mit dem eingebundenen Payback-Konto, aber in die Log-Dateien werden fleißig andere Kontendaten geschrieben.
Antwort des Datenschutzverantwortlichen
Auf Grund der Korrespondenz mit dem Hersteller, die mir vorliegt, kenne ich die Antwort vom Datenschutzbeauftragten, der nach Aussage des Lesers gleichzeitig auch Teamleitung der Fachabteilung ist. Der Leser meint dazu:
Ich finde es nach wie vor sehr bedenklich, dass sämtliche Anmeldenamen aller im Programm hinterlegten Konten übermittelt werden. Das ist in meinen Augen auch in keiner Weise mit dem datenschutzrechtlichen Hinweis gedeckt.
Immerhin ist der oben aufgeworfene Sachverhalt der übermittelten Daten in Punkto Verschlüsselung geklärt, wie aus der nachfolgenden Antwort des Datenschutzverantwortlichen hervorgeht.
Hallo xxx,
vielen Dank für Ihr Schreiben.
Die protokollierten Daten sind – vor dem Versand – auf Ihrem System logischerweise unverschlüsselt. Die Funktion "Logdatei anzeigen", die zur Einsicht in die Daten vorgesehen ist, macht ja nur Sinn, wenn Anwender die Daten auch lesen können. Was Sie sehen, ist genau das, was wir erhalten. Der Versand an uns und das ist der entscheidende Aspekt, erfolgt dann verschlüsselt. Der Punkt "Passwörter" ist durchaus vollumfänglich geklärt. Wie Ihnen Herr x erklärt hat, sind Passworteingaben unkenntlich gemacht. Gleiches steht auch in dem angesprochenen datenschutzrechtlichen Hinweis.
Die Protokollierung hat den Zweck, eine Fehleranalyse zu ermöglichen. Bitte bedenken Sie, dass die Funktion nicht für Sie individuell programmiert wurde oder nur für die Analyse der Abfrage eines einzelnen Kontos, sondern zur für sehr verschiedene Fälle, die in der Vergangenheit aufgetreten sind und die potenziell auch weiter auftreten können. Die Informationen über die Existenz anderer Bankkontakte dient ebenso wie die Bildschirmkonfiguration diesem Zweck. Wenn ein Teil des Namens von Bankkontakten der Anmeldename ist, steht dieser im Protokoll. Der neue datenschutzrechtliche Hinweis deckt das mit ab.
Für weitere Fragen, Anregungen und Hinweise stehen wir Ihnen selbstverständlich gerne zur Verfügung.
Hier ist für den Hersteller klar: Die Daten gehen verschlüsselt über die Leitung und liegen dem Anbieter dann aber unverschlüsselt vor. Wer jetzt spitzfindig ist, kritisiert, dass der Datenschutzhinweis eine "verschlüsselte" log-Datei beschreibt, während in obiger Antwort bestätigt wird, dass diese Datei unverschlüsselt vorliegt. Lediglich zur Übertragung wird die .log-Datei verschlüsselt.
Natürlich benötigt der Anbieter detaillierte Informationen, was ggf. zu einem Fehler geführt haben könnte. Ob aber wirklich Daten von Bankkonten dazu gehören, daran würde ich ein Fragezeichen machen. Ob mein Konto 4711 oder das Konto 0815 der Sparda Bank betroffen ist, sollte egal sein – relevant ist in meinen Augen lediglich die Bank und ggf. der Kontentyp (z.B. Festgeldkonto, Girokonto etc.).
Und es gibt noch einen Punkt, auf den mich der Leser hinwies. Es wird noch die Datei "Useraction.log" angelegt, in der auch noch mal die Kontendaten zu finden sind. Dort ist auch zu jedem Konto ein "KontaktBlob" zugeordnet. Die Frage, die sich stellt: Sind das die jeweiligen unkenntlich gemachten Passwörter, die von Buhl natürlich wieder kenntlich gemacht werden könnten? Eine Antwort ist bisher nicht gegeben worden.
Rechtlich ist das Ganze wohl nicht zu beanstanden, der Anbieter weist die Nutzer auf den Datenschutzaspekt hin und der Anwender stößt die Übermittlung ja auch selbst an. Inhaltlich beschleicht mich aber ein äußerst ungutes Gefühl, wenn eine Software meine Bankdaten an Dritte übermittelt. Jeder Nutzer sollte sich daher im Klaren sein, was er da so tut, wenn er .log-Dateien an die Buhl Data Service GmbH übermittelt.
Man muss der Firma ja nichts böses unterstellen und die werden die Logs nach Abarbeitung des Supportfalls auch löschen. Was aber, wenn in der Zeit von der Übermittlung der .log-Datei bis zur Löschung aller Daten ein Cyberangriff auf dieses Unternehmen stattfindet, bei dem Daten abfließen? Oder was ist, wenn ein Mitarbeiter "vom Glauben abfällt" und die Daten missbraucht? Keine wirklich prickelnde Vorstellung, wie ich finde. Oder wie seht ihr das?
Anzeige
Ohne Worte…
Finger von lassen oder Script zum löschen anwenden.
*der Anwender stößt die Übermittlung ja auch selbst an*
Der Anwender klickt in der Regel auch selbst auf einen Link der dann zu Verschlüsselung des Systems führt…..
Welche andere Wahl hat der Anwender denn wenn es einen Fehler gibt? Daten nicht übertragen und mit dem Fehler leben?
Man kann die Log-Datei auch manuell per Mail an den Support schicken (siehe Screenshot Datenschutzhinweise). Entsprechend könnte man vorher die Log-Datei bereinigen. Aber wer das kann, der braucht meist auch keine Hilfe vom Support…
In der Software sind manchmal Knoten drin bei denen kann nur der Support eine Lösung herbeiführen. Muss nicht immer ursächlich bei Buhl liegen.
Es sind 337 Dateien, die in der Datei Log.zip zusammengefasst werden. Da ist es fast unmöglich, manuell aufzuräumen …
der Name des Kontos ist schon relevant, ein normaler Kunde wird schreiben "als ich die Daten von Konto XYZ abrufen wollte.." irgendwie muss der Support ja auch kommunizieren.
nun könnte man maximal einen Wizard machen der versucht beim nachstellen des Fehlers zusammen mit dem Benutzer die passenden Infos für diesen spezifischen Fall zusammen zu schneiden.
man braucht als Support aber oft auch Infos die ein Gesamtbild erschaffen.
man darf auch immer nicht vergessen das die meisten Nutzer keinen technischen Hintergrund haben aber auch gelöste Tickets haben wollen.
der Kunde kann die Daten vorher ja auch anzeigen und evtl. auch editieren? das würde mich interessieren… ob man in der Anzeige editieren und speichern kann und kann so sensibles auch raus löschen kann.
Ja kann man, ist ne einfache Log Datei die kannst du im Editor bearbeiten.
Selbstverständlich braucht der Entwickler auch die Angaben zu den Konten, den es ist nicht das erste mals das bei solcher Software, die Banken sich gegenseitig in die Quere kommen, der Entwickler muss also wissen welche Banken / Konten beteiligt sind, bei den PW wiederum wird es schon schwierig aber selbst die können Ursachen sein den nicht alle Banken lassen alle Zeichen zu, was ebenfalls teilweise zu komischen Fehlern führen kann. ( Das zum Beispiel alle Zeichen zwar eingegeben werden können später bei der Abfrage aber ignoriert werden, was dazu führt das man keinen Zugriff auf seine Konten mehr hat. Alles schon vorgekommen!)
Das ist halt die Crux: will man ne Lösung oder will man seine Daten geheim halten! Beides geht, aber nicht zusammen. Bei solcher Software ist das halt heikel und man muss sich entscheiden, aber wie gesagt Logfiles lassen sich problemlos editieren und braucht der Entwickler doch editierte Daten fragt der schon nach und man kann dann entscheiden inwieweit man hilft.
Ist halt blöd wenn man dann nen technischer Noob ist und rein gar nix versteht. Technik ist halt nicht für jeden verständlich.
Alten Problem in vielen Bereichen.
Datenschutzkonforme Logfiles zu erzeugen ist nicht ganz ohne.
Da reichen schon geloggte SQL Statements mit und ohne Resultat für einen handfesten Gau.
Gruß
Datenschutztkonform bedeutet nicht das solche Daten nicht enthalten sein dürfen! Wenn sie für die Bearbeitung notwendig sind erlaubt die DSGVO das durchaus, sie dürfen nur nicht einfach so grundlos erhoben werden! Verstehen die Leute nur nicht.
Die DSGVO verbietet mitnichten das persönliche Daten erhoben werden dürfen, sie regelt nur sehr genau wann und wie das der Fall sein darf!
Einfaches Beispiel wenn du bei mir etwas bestellst brauche ich dein Name & Adresse, sonst kriegst du nix! deine sexuellen Vorlieben brauche ich dazu aber nicht zu wissen (außer du bestellst entsprechenden Service ,-P)
Yeap,
häufig genug schon erlebt das durch Gedankenlosigkeit oder satte Fehler im Code Informationen geloggt wurden die einen dann nur noch fassungslos werden lassen.
Nicht das es Lösungen für solche Aufgabenstellungen geben würde aber ganz offensichtlich brauchen viele den Schmerz wenn der Datenschützer anklopft.
Darum kann der User i.d.R. einstellen, wie tief gelogt werden soll und wann.
Das muss natürlich schon in der Software angelegt sein.
Das hat bei hoch sporadischen Fehlern natürlich den Nachteil, das man erst dann Daten hat, wenn der Kunde das Logging Freigegeben hat und der Fehler noch mal auftritt.
Z.B. ist es nicht zulässig alle Telefonate im Detail mitzuloggen.
Das darf erst erfolgen, wenn ein konkreter Missbrauch entdeckt wurde. Z.B. Stundenlange Gespräche in Richtung Zone 3…
Ist natürlich unschön für den Arbeitgeber, aber alles andere wäre eine anlasslose Überwachung von Mitarbeitern und Kunden.
Habe dieser Art Software immer misstraut und sie gemieden. Irgendwann wird fast immer klar, dass das kein Fehler ist.
Den Ausführungen des DSB kann ich nur in Teilen folgen, auch sehe ich in seiner Tätigkeit als vermeintlicher Teamleiter der Fachabteilung eh einen Interessenskonflikt vorliegen.
"die Antwort vom Datenschutzbeauftragten, der nach Aussage des Lesers gleichzeitig auch Teamleitung der Fachabteilung ist. "
Ich erinnere mich an eine Datenschutz-Schulung, in der explizit darauf hingewiesen wurde, das so eine (sicherlich naheliegende) Kombination nicht zulässig ist.
Der Leiter der Fachabteilung würde sich ja selbst überwachen… Das das nicht geht sollte eigentlich jedem klar sein…
Der DSB muss unabhängig sein.
Das kann bei kleinen Firmen bedeuten, dass man einen externen DSB beauftragen muss.
Man spart sich beim ext. DSB die notwendigen Schulungen und den besonderen Kündigungsschutz eines eigenen DSB s und wenn der externe DSB zu unbequem wird, kann man diesen schneller wechseln als einen internen. Auch spart man sich evtl. Diskussionen mit dem Betriebsrat. Auch sickert nichts per Flurfunk den externen DSB zu, der interne Könnte z.B. in Kantine schon was hören.
Ja, so habe ich das auf gelernt. Oder halt einen internen, der so gar nix mit der Abteilung zu tun hat. Aber den Teamleiter halte ich für bedenklich. Dann könnte es ja auch gleich der Geschäftsführer machen.
Ganz genau.
Ein DSB darf weder Gesellschafter noch Teil der Geschäftsleitung sein.
Auch darf er nicht in der IT-Abteilung arbeiten, wenn er da mit entsprechenden Vorgängen und Software zu tun hat.
Denn dadurch entsteht grundsätzlich ein Interessenkonflikt. Der DSB darf auch nicht weisungsgebunden sein und er hat einen besonderen Kündigungsschutz.
Der DSB muß allerdings nicht zwingend im Unternehmen angestellt sein.
Ein Leiter der IT-Abteilung kommt daher als DSB grundsätzlich nicht in Betracht.
Für Entwickler ist durchaus relevant, welche Bildschirm konfiguration, welche Dll Version etc. verwendet wird.
Das ist "notwendig".
Es macht einen Unterschied ob der Kundebauf einen 1024×756 oder mehreren 8k 19:12 Displays arbeitet.
Beim Einreichen des Bugs ist nicht bekannt wo das Problem liegt. Und für den Entwickler ist es extrem nervig und ineffizient, wenn der Kunde aus Tippfaulheit, nur seine Interpretation des Fehlers schickt ("der Bildschirm wurde plötzlich blau")
und erstmal um die original Meldungen bieten muß.
Die Kontodaten können in einem symbolischen Name verarbeitet werden.
Natürlich muss der Entwickler wissen, welche Bank der Kunde benutzt. Das Passwort braucht er auf keinen Fall, zumal dieses heute i.d.R. durch eine 2. Faktor geschützt ist.
Es ist natürlich sehr kompliziert, ins Log File nur die Bankverbindungen zu schreiben, von der der Kunde glaubt, das sie für den Fehler verantwortlich ist.
Die ersten Stellen der Kontonummer können auch relevant sein, da man aus diesen u.U. feststellen kann, was für ein Konto-Typ das ist.
.
Natürlich muss hier eine EndZuEnd Verschlüsselung erfolgen. Eine reine Transport Verschlüsselung ist ganz klar unzureichend.
Problematisch ist natürlich, das die Daten auf der Platte des Kunden im Klartext vorliegt.
Anderer Seite will man gegenüber dem Kunden Transparent sein.
Das was Buhl da macht ist aber harmlos und durch aus datenschutzfreundlich, da die Daten nur auf den eigenen Rechner geladen werden.
Mit PSD2 wurde die Möglichkeit geschaffen, dass Drittanbieter sich(!) sämtliche Kontoauszüge besorgen kann.
Ideal für einen Strukturvertriebler.
Der kann nach einiger Zeit sehen, welche Versicherung der Kunde wo hat. Teilweise geben die Kunden diese Daten selbst ein.
Für einen Strukki ist es wichtig die Belastbarkeit des Kunden zu kennen, denn den Kunden in die privat Insolvenz zu treiben ist nicht das Ziel wohl aber zu u eigenen Versicherungen, so das der Strukki die Provisionen bekommt…
Problem:
Bei der Postbank z.B. erhält der Kunde derzeit keine Möglichkeit zu sehen, wie oft der Drittanbieter auf das Konto zugegriffen hat
Es soll lt. Internet vorgekommen sein dass auch nachdem der Vertrag gekündigt worden ist, weiter auf Konto zugegriffen wurde. Auch gibt's bei der Postbank keine Möglichkeit eine einmal erteilte Ermächtigung zu widerrufen. Besonders da z.Zt. die Postbank 2 Stunden Telefonwartezeit hat, und E-Mail nur per Eingangsbestätigung beantwortet werden…
"Die protokollierten Daten sind – vor dem Versand – auf Ihrem System logischerweise unverschlüsselt"
Welche Logik soll das sein, Werter Herr Teamleiter?
Microsoft logged auch in verschlüsselte/verschleierten Dateien.
Auch in anderen Fällen habe ich schon
verschlüsselte oder verschleierte Logs gesehen.
Aber es ist ein 2-schneidiges Schwert denn:
Nur "keine Daten" sind "sichere Daten".
naja die liegen auf deinem Rechner unverschlüsselt wegen der Transparenz: du sieht vorher genau was du da an den Entwickler schickst und kannst damit genau abwägen! Bei Microsoft sieht du nix, du musst dich darauf verlassen das das stimmt was M$ behauptet (wers glaubt ;-P )… da ist mir die "Buhl Methode" doch lieber!
Zumal ich das Ganze vor dem verschlüsselten Versenden auch noch bearbeiten kann.
Irgendwelche kryptischen Logs bei dennen nur der Hersteller weis was da drinn steht sind nicht vertrauenswürdig!
Na ja, es sind 337 Dateien, die in der Datei Log.zip zusammengefasst werden. Da ist es fast unmöglich, manuell aufzuräumen …
naja ist Arbeit ja… läßt sich ja aber auch automatisieren, einfaches Suchen und Ersetzen kann jeder Editor. Bessere beherrschen auch richtiges Scripting… Nen Script das da die PW etc. rausfiltert ist in wenigen Minuten durch…
Du hast ja keine unedliche Anzahl an schützenswerten Daten, oder?
Das sollte einem seine Privatsphäre schon wert sein … und Hilfe willst du ja auch, da muss man eben Kompromisse eingehen.
Lieber Gott wasch mich, aber mach mich nicht nass funktioniert halt nicht.
Ich fürchte das der übliche Bohl Software Nutz mal gerade weis wo das Kabel der Maus weisen muss aber definitiv nicht in der Lage ist Scripte zuschreiben. Far auf dem schwarzen Fenster.
Anyway wird für für Klicks aus einer Mücke ein Elefant gemacht.
Eine Kontonummer ist kein Geheimnis.
Was Microsoft hätte machen müssen wäre generelle Log Files level vorgeben und verwalten müssen.
Das ist aber etwas, was MS nicht kann.
Neulich fand ich ein ständig Wachsendes Verzeichnis, das schon auf 2GB angewachsen war, was den Akkubedarf des Users loggte…
2GB sind doch Peanuts.
Klar, wenn man für sein Backup viel Zeit hat…
Und es nicht der einzige Müll den MS anlegt aber nie abräumt.
@pau1: Es wäre gut, die Kommentare in der Anzahl etwas zu begrenzen und den Text doch ggf. nochmals vor dem Absenden zu lesen. Der obige Kommentartext ist eine Herausforderung für den Leser und bingt jetzt nicht mehr so arge Erkenntnisgewinn für die Leserschaft.
Die Kommentarflut konterkarriert den Informationsfluss, den Leser in den Kommentaren erwarten. Gab von anderen Lesern ja bereits ähnliche Anmerkungen. Nichts für ungut.
". Ob mein Konto 4711 oder das Konto 0815 der Sparda Bank betroffen ist, sollte egal sein – relevant ist in meinen Augen lediglich die Bank und ggf. der Kontentyp (z.B. Festgeldkonto, Girokonto etc.)."
Jein.
Es wurden irgendwann mal die länge der Kontonummern auf 10 stellen erweitert.
Manche Software hatte danach Probleme, weil sie die 9 Stellingen durch Anhängen einer Null 10stellig machte. Das ging gründlich schief. Warum sollte man das auch vorher Testen? War eh nur für ALG2 Empfänger, und die können doch schon Mal einen Monat ohne Geld auskommen…
In sofern kann die Kontonummer wichtig sein.
Aber die Kontonummer ist ja kein großes Geheimnis.
Allerdings müsste das Passwort so verschleiert sein, das man es nicht wieder gewinnen kann.
Auch kann ich mir gut vorstellen, daß ein Kunde sich bei der Kontonummer vertan hat, die zu einem anderen seiner Konten gehört.
In denke da an ungewollte Untermieter auf dem PC,
weniger an den Hersteller.
BTW:
Das da ein Teamleiter der Datenschutz Beauftragte sein soll kann ich mir nicht vorstellen.
Der Offizielle DSB ist unter Datenschutz (at) buhl-group.de zu erreichen.
Ich vermute Mal, das der Teamleiter nur für interne Umsetzung der Anweisungen des DSB zuständig ist.
Bei 3700 Mitarbeitern muss die Arbeit ja irgendwie verteilt werden.
Allerdings verwendet auch Buhl
keine SPF oder DMARC im DNS.
Immerhin ein TTL von 3600 (86400 wären empfehlenswerter, aber wenn man eh kaum DNS Abfragen bekommt…)
Schau mal hier: https://www.buhl.de/datenschutz/
Da steht:
"Verantwortliche Stelle für die Datenverarbeitung ist (s.Impressum):
Buhl Data Service GmbH
Am Siebertsweiher 3/5
57290 Neunkirchen
Telefon 02735 90 96 99
E-Mail: datenschutz-anfrage@buhl.de"
Unter dieser Mail-Adresse schrieb mir der gleiche Mensch, der laut XING auch "Teamleiter Support Finanzsoftware" ist. Ich habe auch schon einige Supportmails von ihm bekommen.
Ich sehe da einen extremen Interessenkonflikt …
Ja, dacor. Wobei ein "Teamleiter" ja nicht unbedingt entscheiden ob und wieviel Geld für den Datenschutz ausgegeben wird… insofern besteht kein Interessenkonfikt…aber sieht nicht gut aus.
Beauftragter vs.
Bevollmächtigter
Und natürlich macht es Sinn als "Antwort An" eine Funktionsadresse zu verwenden um den Vorgang zu dokumentieren…
Hm, das Buhl zulässt, das sein Mitarbeiter mit
Firmenname auf xing zu finden ist… erstaunlich.
Bei machen Unternehmen wird das untersagt um evtl. Korruption/Abwerbung vorzubeugen.
(Und auch zum Erschweren von social Engineering für Cyberangriffen.).
An all den länglichen Datenschutzerklärung haben sich offensichtlich Anwälte gütlich getan insofern ist zu vermuten daß das 200%ig OK ist.
Die Strafen können heftig sein, wenn man den Falschen zum DSB bestellt hat
Und dann war da noch die Holding, die explizit
von "Datenschutzbeauftragten" spricht.
Aber auch nur für die Webseite!
Der zuständige DSB ist der jeweiligen
App zu entnehmen.
Magst Du Mal schauen was da in der App oder Programm steht?
(2)Verantwortlicher gem. Art. 4 Abs. 7 EU-Datenschutz-Grundverordnung (DSGVO) ist die
BUHL Services GmbH
Alfred-Nobel-Straße 9
86156 Augsburg
(3) Unseren Datenschutzbeauftragten erreichen Sie unter datenschutz@buhl-gruppe.
https://www.buhl-gruppe.de/datenschutz/
(1) Im Folgenden informieren wir über die Erhebung personenbezogener Daten bei Nutzung unserer Website und von Sub-domains unserer Webseite.
https://www.buhl.de/datenschutz/
Diese Datenschutzerklärung bezieht sich *nur* auf die öffentlich zugänglichen Web-Seiten
der Buhl Data Service GmbH sowie
den geschützten Bereich des Kundencenters.
Aber das ist hier mangels Infos nicht lösbar
Im Programm gibt es unter Hilfe den Punkt "Datenschutzbestimmungen", der auf diese Webseite verlinkt ist:
https://www.buhl.de/dse/datenschutzhinweise-zur-belegerfassung/
Wenn ich in der Online-Hilfe nach Datenschutz suche, findet er nur die "Willkommen" Seite, auf der folgendes steht:
"Noch ein Wort zum Thema Datenschutz: Mein Geld wird von der Buhl Data Service GmbH hergestellt. Weder das Unternehmen noch seine Mitarbeiter haben Zugriff auf Ihre vertraulichen Daten! Das gilt sowohl für Ihren PC als auch für die Übermittlung Ihrer Aufträge an die Bank und die Onlinekomponenten LetsTrade. Die Datensicherheit wurde von unabhängigen Institutionen geprüft und bestätigt. Sie können Mein Geld also ganz unbesorgt einsetzen."
Mehr kann ich zu dem Thema nicht finden.
Da in diesem Fall alle Daten bei Dir sind, arbeitet keiner von Buhl mit Deinen Daten elektronisch, also ist dafür kein DSB etc. nötig.
P.S.
Die Buhl Gruppe hat erst mal nix mit der Buhl-Software zu tun:
https://www.buhl-gruppe.de
Da geht es um "Dienstleistungen für Hotellerie & Gastronomie"
Wenn man sich umschaut, sieht man, dass "Pau1" es mit Details und Hintergründen nicht so genau nimmt, Hauptsache irgendetwas kommentiert. Das verwässert den hier sonst üblichen technisch sachlichen Austausch (inzwischen leider) merklich.
Die Kontonummer trägt bei einigen Banken zusätzliche Informationen. Z.B. war es einst üblich, das Plus-Konten einem bestimmten Nummern Kreis zugeordnet wurden. So konnte jeder, ohne die Schufa kostenpflichtig abzufragen, sofort sehen, das es evtl. bei dem Kunden ein Problem mit der Kreditwürdigkeit gibt…
Also es gibt genug Gründe die genaue Kontonummer zu erkennen.
Ja, na klar. Das ist rechtlich, technisch nicht zu beanstanden, wenn sensible Zugangsdaten, die generell verschlüsselt in einer Datenbank stehen, im Klartext lokal in die Logs geschrieben werden.
Grad bei FinTech Software sollte bekannt sein, dass das selbstverständliche Praxis ist.
Man kann Dateien ja auch wieder löschen und natürlich ist es auch normale Praxis in Log Files rumzueditieren um ggf. sensibles raus zu löschen.
Ich verstehe die Aufregung nicht. Als könnte lokal jemand drittes damit irgend was anfangen. /s
a) bei über 300 Log-Dateien die sensiblen Informatuionen wieder raus löschen? (ja, geht, mit notepad++ kann ich suchen&ersetzen über alle geöffnete Dateien gleichzeitg nutzen, aber bei über 300 Dateien dürfte das auch ein Ressourcenproblem auf dem PC werden…)
b) Die Logdateien liegen da, auch wenn man sich einen Trojaner/Ransomware/… einfängt. Der Angreifer macht da dann fette Beute.
c) Ist das ZIP, welches da übertragen wird, denn wenigstens Passwort-geschützt?
Wenn man sich den Umgang der Firma mit dem Kunden über die Jahre anschaut, treibt es mir die Zornesröte ins Gesicht. Es wurde jedes Jahr schlimmer.
* Nötigung zum Kundenkonto, sonst keine Updates
* Speichern der Daten bei Buhl als Komfortgründen, lokales Speichern muß man explizit auswählen.
* Einschränken der Nutzung eines Lizenzschlüssels auf wenige Steuererklärungen
* Wegfall der einfachen "Start" (15 €)Version und Zwang zum "Vollpaket" (30€)
sind nur einige Punkte, die mir jetzt einfallen.
Naja Umstellung auf Online und Abo hast du doch überall… außer im Open Source Bereich wo man kein Geld verdienen möchte!
Buhl ist jetzt auch nicht den Laden den ich bevorzugen würde, hat aber mit der Sache rein gar nix zu tun.
Hier wird ein Datenschutz Fass aufgemacht wo keines ist! Die Daten sind zur Fehleranalyse notwendig, welche auch vom Kunden angestoßen wurde und nicht abgeschnorchelt, die Übermittlung geschieht verschlüsselt … für Datenhypochonder lässt sich das Ganze sogar vorher ansehen und editieren. Da gibt es also nix zu beanstanden!
Dann wird sogar noch der Status des Datenschutzbeauftragten in Frage gestellt … (Datenschutzbeauftragter kann auch jemand sein der noch andere Funktionen in einer Firma bekleidet. Teamleiter Support ist jetzt auch nicht eine Position die dem Wiederspricht. Teamleiter kann auch ein einfacher Arbeiter sein wenn sich das Team selbst leitet, dann ist das nichtmal nen direkter Vorgesetzter. Kann evtl. Wiedersprüche bringen, aber dazu müsste man schon tiefere Kentnisse der Organisationsstrukturen der Fa. Buhl haben.)
Sorry, aber nichts was hier vorgebracht wurde, ist da tasächlich relevant oder haltbar.
Das in einer Finanzsoftware sowohl Konten wie auch PW relevant zur Fehleranalyse sind ist nunmal Fakt! Sowohl Konflikte zwischen Bankkonten (z.B.: Nummernbereich) als auch PW Konflikte (Zahlen Ziffern Sonderzeichen) können zu Fehlern führen die dann Analyserelevant sind und daher diese Daten erfordern (was die DSGVO auch zuläßt, die DSGVO besagt mitnichten das kein persönlichen Daten gespeichert/übertragen werden dürfen… sie besagt das nur relevante persönliche Daten verwendet werden dürfen, was hier der Fall ist.) Würde hierbei noch die Religion, die Politische Richtung oder die sexuelle Ausrichtung mit abgefragt, dann wäre das ein DSGVO Verstoß! den diese Daten wären zur Fehleranalyse nicht notwendig und somit unberechtigt abgefragt und persönlicher Natur.
Was hier jedoch nicht der Fall ist.
Fragen:
-Wird die Logdatei nur erstellt wenn es ein Problem gab oder kann man damit rechnen, dass man generell Logdateien in den Programmordnern findet? Die Logdateien werden dann auch nicht nach Übermittlung "gelöscht"?
-So wie ich es lese würde, werden die Passwörter und kritische Zugangsdaten nicht im Klartext in den Logdateien gespeichert. Wenn das der Fall wäre, dann könnte ja theoretisch jeder mit der Windows-Nutzeranmeldung oder den entsprechenden Rechten auf die Logdatei zugreifen….
-Warum werden diese Daten "unkenntlich" gemacht und nicht durch Dummy-Werte ersetzt? Werden jetzt die Zugangsdaten gar nicht in den Logdateien gespeichert oder unkenntlich gemacht? Ist mir nicht ganz klar. "Unkenntlich machen" heißt für mich, dass die Daten nicht mehr wieder herstellbar sind. Alles andere wäre verschlüsseln.
-Die Übermittlung der Logdateien erfolgt dann ausschließlich über das Programm? Man wird auch an keiner Stelle aufgefordert die Logdateien per Mail zu schicken.
Ich habe neben WISO MeinGeld auch noch das Multibanking-Tool Finanzblick der Firma Buhl im Einsatz, das neben einem Zugang per Webbrowser auch eine Android-App anbietet.
Ich hatte damit zuletzt einige Probleme (unnötig zusätzliche 2FA) beim Abruf einiger (Verrechnungs-)Konten meiner Bank, die andere Multibanking-Apps (z.B. die Sparkassen-App) nicht hatten. Nach Rücksprache meiner Bank liegt das Problem demnach an Finanzblick bzw. am Finanzblick-Server von Buhl. Mir blieb also nichts anderes übrig, als dem Support wie gewünscht ein Logfile der App zu übermitteln, damit die Kommunikation zwischen Finanzblick-App und -Server analysiert werden kann.
Gemäß der Anleitung des Buhl-Supports sollte die App im Logmodus gestartet und danach lediglich gezielt die betroffenen Konten einzeln manuell abgefragt werden, also kein automatischer Kontenrundruf über sämtliche weiteren eingerichteten Banken und Depots.
Danach auf den Button "Logfiles senden" klicken, worauf unmittelbar danach der Logmodus automatisch beendet wurde, sodass noch nicht mal mehr lokal (im PC-Webbrowser oder auf dem Smartphon) andere Konten+Zugangsdaten mitgeloggt wurden.
Außerdem versicherte man mir, dass der Datenversand verschlüsselt geschieht, und die Daten bei Buhl den geforderten Datenschutz bekommen.
Ich finde, das alles ist ein lobenswertes Vorgehen – natürlich in der Annahme dass alle Zusagen von Buhl bzgl. Datenschutz eingehalten werden.
…Die Geschichte mit den Netkeys, die meistens von Volksbanken genutzt werden, ist mir bisher immer sehr supekt gewesen. Ich meine: wer geht denn davon aus, dass sich auch in einer Zugangskennung (eine Art "Kundennummer") streng vertrauliche Daten befinden, so wie ein Passwort, obwohl die Zugangskennung in den Anwendungen nirgends mit Sternchen angezeigt wird, sondern überall im Klartext ?
Da liegt doch der Fehler eher systematisch bei der Bank, die solche Netkeys verwendet, und nicht beim Multibanking-App-Anbieter, oder !?
"Gemäß der Anleitung des Buhl-Supports sollte die App im Logmodus gestartet und danach lediglich gezielt die betroffenen Konten einzeln manuell abgefragt werden, also kein automatischer Kontenrundruf über sämtliche weiteren eingerichteten Banken und Depots."
Genau das ist ja das Problem. Auch bei dieser Vorgehensweise werden die Daten aller eingetragenen Banken übertragen. Man muss dafür keinen Rundruf über alle Konten machen. Bei mir war es nur der Abruf des Payback-Kontos und es waren alle Daten in den Logfiles.
Ok, aber das Absenden geschah dann transportverschlüsselt und ohne Login-Passwörter im Klartext, oder ? Das Problem ist demnach die übermittelte Login-Zugangskennung (Kundennummer oder Netkey o.ä.) im Klartext, oder versteh ich das falsch ?
…Bliebe dann eine Risikoabschätzung übrig, ob es wirklich ZU kritisch-riskant ist, FALLS eine Login-Zugangskennung tatsächlich danach von Buhl "entwendet" wird (ohne zusätzliche Referenz oder Nennung von realem Kundennamen, Emailadresse, o.ä.)
D.h. ob jemand allein mit Kundennummer oder Netkey überhaupt etwas anfangen kann. Denn bei Datenleaks werden die geleakten Daten meistens 1:1 en bloc aus einer geklauten Datenbank verwendet, ohne dass jemand parallel noch eine aufwendige weitere Datenrecherche und -Verknüpfung dazu macht. (Ok, auch wenn man sowas gern Google und Co. in ihrer Datensammelwut unterstellt, aber die werden keine Daten von Buhl klauen…)
Ob die Daten verschlüsselt übertragen werden, kann ich nicht beurteilen. Da muss ich mich auch auf die Aussagen von Buhl verlassen.
Ob Passwörter im Klartext oder verschlüsselt übertragen werden, ist erst mal sekundär, ich möchte, dass die GAR NICHT übertragen werden.
Da ist auch die Ausage in den Hinweisen unklar:
"PINs und gültige TANSs … werden in keinem Fall im LOG-File verzeichnet, sondern immer unkenntlich gemacht".
Sind die nun verschlüsselt/unkenntlich im Log enthalten oder nicht? Warum der Hinweis "unkenntlich gemacht" wenn sie "in keinem Fall im LOG-File" sind?
Es gibt in der großen Log.zip die Datei "Useraction_.log", wo in meinen Augen alle Konten in folgender Form zu sehen sind:
HBCIName: Sparkonto
KontaktID: HBCI_PLUS_25090500_232xxxxxx
KontaktBlob:0003eyJibG9iIjoiUEQ5NGJXd2dkbVZ5YzJsdmJ[…]Y21saGJHbDZaV1ErIiwidHlwZSI6MH0=AccessType:100
(Daten geändert)
Mich würde da mal brennend interessieren, was dieses "KontaktBlob" ist. Das Bank-Logo wird es wohl nicht sein.
Man könnte spekulieren, aber so was tun wir ja nicht …