Ich kann das weder bestätigen noch verneinen

Vorweg erst einmal vielen, vielen Dank an Olaf Willuhn für die viele Arbeit an Hibiscus und den schnellen Update auf die 2.10.23. Nach dem Löschen und Neuanlegen des Bankzugangs hat alles funktioniert.

Kritik geht an die DKB für den Wegfall von ChipTAN-USB. Wenn ich mit meinem noch nicht sehr alten Cyberjack One weitermachen will, gibt es nur ChipTAN manuell. Statt (nach Anlegen der Überweisung) einmal die PIN und zweimal OK einzugeben, muss ich jetzt
* die PIN eingeben
* einen Startcode eingeben
* eine Tan eingeben
* noch einen Startcode eingeben
* zehn Stellen der IBAN eingeben
* den Betrag eingeben.
* die Tan eingeben

Na, wenn das mal nicht kundenfreundlich ist.

Das schreit alles nach "benutz doch einfach das Handy, das machen alle so"
Nein, das ist für mich keine Option, ich möchte keine Bankingsoftware, auch keine TAN-Generatoren auf dem Smartfon haben.
Bei ChipTAN-QR (€30 für das Gerät) wird es wohl weniger schlimm, nur noch die TAN muss am Ende abgeschrieben werden, immer noch viel komplizierter als vorher und vor allem fehleranfällig.

Ich frage mich jetzt, warum können die Infos nicht mehr über USB zum Kartenleser und zurück übertragen werden?
Gibt es neben der "Kundenlenkung" nach Onlinebanking oder Handy irgendeinen sachlichen Grund, die USB Übertragung abzuschaffen? Sicherheitsbedenken?

Das ChipTAN-USB ist wohl technisch recht dicht am ChipTAN optisch/flicker so dass bei Banken, die offiziell ChipTAN USB nicht
unterstützen, in Hibiscus ChipTAN optisch ausgewählt werden kann. Statt des optischen Lesers kann dann transparent die Überweisungsinfo über USB übertragen werden. Kann man das in Hibiscus nicht auch basierend auf dem von der DKB noch angebotenen ChipTAN QR implementieren, quasi als USB Übertragung der im QR enthaltenen Überweisungsdaten und den TAN zurück über USB? Könnte ggf. ReinerSCT das?

Bei ChipTAN optisch erhält die Anwendung exakt die Daten, die auch per USB an den Chipkartenleser geschickt werden. Deshalb ist das hier problemlos. Bei ChipTAN manuell erhält die Anwendung nur den Freitext der angezeigt wird. Daraus die Daten für die Chipkarte abzuleiten ist praktisch unmöglich. Bei ChipTAN QR erhält die Anwendung nur ein Bild (PNG). Daraus könnte man evtl. die Daten ableiten, wenn man den QR Code scannt. Ist aber auch nicht so ganz ohne. Fazit: Es fehlen einfach die Daten, die per USB an den Leser geschickt würden.

Fragt sich noch, wieso sich die DKB chipTAN Optisch gespart hat. Hätte wohl zusätzliches Geld gekostet...

Der derzeitige HBCI-Server ist für DKB-Geschäftskunden, z.B. Hausverwaltungen mit großen Mengen von Konten, kaum mehr nutzbar. Die müssen jetzt wohl auf EBICS umsteigen, was bei entsprechender Software teuer wird...

Das ChipTAN USB nicht mehr geht ist ne Katastrophe.

Ich glaube die Antwort auf deine Frage kann man auch in diesem Posting zwischen den Zeilen herauslesen: forum/topic.php?p=173726#real173726
Btw: super beeindruckend, wie schnell du das Hibiscus-Problem gestern gelöst hast Also ganz großes Lob!

Es wäre super, wenn der Bluetooth-Modus wieder hergestellt würde.

Der tanJack Bluetooth ist eine super (die beste?) Art, Sicherheit und Komfort zu vereinen.


Das verstehe ich nicht so ganz.

Aus dem Text müsste doch für die allermeisten Transaktionen bei der DKB nur der Startcode ausgelesen werden. Der sollte doch problemlos zu erkennen sein?

Nach meinem Kenntnisstand ist das einzige bei der DKB, was nicht per Startcode funktioniert, Überweisungen. Klar, es wäre schön auch die zu automatisieren (und auch das ginge vermutlich), aber ich könnte damit leben, für diese chipTAN manuell zu machen. Für den täglichen Rundruf hingegen ist manuell schon *sehr* nervig, und wenn man den Startcode auslesen würde, könnte man bereits Kontorundrufe per Bluetooth ermöglichen.

Ich kann auch anbieten, die verschiedenen Textprompts der DKB zu sammeln, und hier zu posten.



Das wäre natürlich die elegantere Lösung, als irgendwelchen Text zu zerlegen.

Das wäre natürlich etwas mehr Arbeit, aber es müsste doch zahllose Libraries geben (vermutlich auch open source), die den QR-Code dekodieren können. Android hat die entsprechende Funktion auch bereits als API eingebaut: https://developers.google.com/ml-kit/vision/barcode-scanning

Diesen Startcode kann man aber nicht per Schnittstelle an das Gerät übetragen, weil es dafür keine Schnittstelle gibt. Selbst wenn man den Code irgendwie hinsenden würde - das Gerät würde damit nichts anfangen können. Bei ChipTAN USB/Bluetooth wird *nicht* dieser Startcode an das Gerät übertragen sondern komplett andere Daten. Die Herausforderung ist also nicht, diesen Code aus dem Text zu extrahieren sondern dass die für die Übertragung nötigen Daten gar nicht vorliegen.

Danke für die Klarstellung, das hatte ich oben nicht richtig verstanden.

Dann müsste man wohl doch über den QR-Code gehen. Enthält dieser die gleichen Daten wie der Flickercode?

(Wenn ich Herrn Selle oben richtig verstanden habe, enthalten Flickercode und USB exakt die gleichen Daten, also hoffentlich der QR-Code ebenso?)

Hallo, die Daten sind nicht 100%ig exakt, aber sie enthalten alles was man braucht, um daraus einen Datenblock für Chip-TAN Bluetooth zusammenbauen.

Die Freigabe via APP verfehlt aus meiner Sicht sowieso komplett das eigentliche Ziel: es wird überhaupt nicht angezeigt, was freigegeben wird. Ein man-in-the-middle-Angriff kann somit nicht erkannt werden.

Die ständige Nachfragerei wg. jedem Quatsch (bei der Neusynchronisierung des Zugangs waren das, wenn ich mich noch richtig erinnere, 4 Freigaben) und bei der terminierten Überweisung 2 führt sowieso dazu, dass man schlussendlich alles abnickt und zum Ja-Sager wird. Sicherheit vollkommen ad absurdum geführt und das komplette Gegenteil von dem erreicht, was man eigentlich erreichen wollte. Da haben mal wieder einige nicht mitgedacht.

Ich will die ChipTAN via USB oder bluetooth wieder haben!

Das sehen die Entscheidungsträger der DKB aber anders. Hauptsache hip und woke

Natürlich sieht man, was freigegeben wird. Bei Überweisungen fehlt lediglich der Verwendungszweck:

Allerdings sieht man nicht, ob es sich um eine Überweisung, Terminüberweisung oder einen Dauerauftrag handelt.

Und eine HBCI-Nutzung ist keine Web-Anmeldung.

Anzeige der Empfänger Namen statt nur Iban ist auch nicht die beste Lösung. Zumindest bis es die verification of payee regulation demnächst gibt.
Ich könnte heute an peter parker überweisen aber meine Iban angeben. Was prüfen die Leute wohl auf so einer Ansicht?

Ich denke, es ist alles gesagt. Das ganze wird (bei mir) noch dadurch getoppt, dass die App bei dem Prozess entweder crashed oder hängt (nach der Freigabe). Da ja für jeden Auftrag mindestens zwei Bestätigungen nötig sind, ist das maximal ärgerlich.

Die Bestätigung der Anmeldung am Web kommt wohl daher, dass hier ein Scraper im Einsatz ist (wie kann man nur auf eine solche Bastelidee kommen?). Offensichtlich ist man da nicht mal willens, zwischen HBCI und echtem Web-Zugriff zu unterscheiden. Für mich deutet das wieder ganz klar darauf hin, dass das HBCI bei der DKB mittlerweile eine reine Notlösung ist, die man ursprünglich gar nicht mehr wollte, was man dann im wahrsten Sinne des Wortes bastelmäßig draufgesetzt hat. Die Performanceverluste durch den Scraper-Flaschenhals sind nicht relevant, weil die HBCI - Schnittstelle wahrscheinlich kaum frequentiert ist (bzw. das so angenommen wird). Man hat ja jetzt auch alles dafür getan, um sie den Kunden so madig wie nur möglich zu machen.

Außerdem gilt: wenn die Web-Anwendung überlastet / ausgefallen ist, ist zukünftig auch HBCI tot. Ganz toll. Abgesehen davon sehe ich es schon kommen, dass Änderungen in der Web-Anwendung vergessen werden, im Scraper nachzuziehen. Was dann zur Folge hat, dass HBCI spinnt. Erklär das mal einem MA der DKB, der bei HBCI nur mit den Achseln zuckt, weil er keine Ahnung hat, wovon man spricht, weil er die eigenen Produkte nicht kennt. Alles schon erlebt.

Kannst du mal bitte erklären, wie du auf die abenteuerliche Idee kommst, dass hier ein Scraper im Einsatz ist und wo genau sich dieser deiner Meinung nach befinden soll?

Natürlich ist hier ein vollwertiger FinTS-Server im Einsatz, ohne Scraper. Diese halbgare "Made with Love in Berlin"-App kann einfach nicht vernünftig zwischen Web-Anmeldung und HBCI-Anmeldung unterscheiden.
Man sieht das doch auch schön bei den unterschiedlichen Geschäftsvorfällen Überweisung, Terminüberweisung, Dauerauftrag: in allen drei Fällen sieht die Bestätigungsabfrage in der App exakt identisch aus. Weil sich die Berliner Entwickler einfach die Arbeit gespart haben, hier unterschiedliche Bestätigungsabfragen in der App zu bauen. Gleiches gilt für Web-/HBCI-Anmeldung.

Es wurde schon alles geschrieben zu dem ganzen Mist den die DKB nur noch produziert.
Ich habe neun Konten dort. Ich werde irre.
Hat jemand einen Tipp für eine Bank die damit (UX) noch vernünftig umgeht und für den Kunden anstelle gegen den Kunden entwickelt?

Habe in Hibiscus die Umstellung der DKB Konten hinbekommen. Die Girokonten werden angezeigt, aber die Hauskredite sich nach der Umstellung außen vor.

Wie kann ich es anstellen, dass ich die Umsätze der Kredite wieder abrufen kann?

Vielen Dank.