Servus zusammen,

hat jemand ein Patentrezept für folgendes Problem mit der Deutschen Bank und HBCI mit Pin und Tan (aber dann auch noch mit gemeinsamer Unterschrift):

Unter BTX war es schon eine komische Handhabung bei der gemeinsamen Unterschrift, denn SFIRM32 verlangte zunächst die PIN des ersten Teilnehmers und dann die PIN des zweiten Teilnehmers. Normalerweise erwarte ich nach selbem Schema die Eingabe der TAN's (zuerst der Eine, dann der Andere). Pustekuchen: Bei der TAN-Eingabe konnte man immer nur ein und dieselbe TAN (von einer TAN-Liste) im Namen beider Teilnehmer verwenden.
Technisch hatte ich keine Erklärung dafür, aber man konnte sich damit arrangieren.

Seit HBCI mit PIN/TAN verlangt SFIRM32 ebenfalls 2 PIN's und 2 TAN's, aber der gute Trick mit der gleichen TAN zieht absolut nicht mehr. Von der DeuBa-Hotline, wurde mir auch bestätigt: Ja, 2xPIN, aber nur eine TAN! SFIRM32 verlangt aber zwingend gemäß HBCI-Standard nach 2 TAN's. Ist ja auch in Ordnung, aber die BIVG war nun selber ratlos, was man nun tun kann. Selbst StarFinanz sagt, dass dieses Problem bekannt ist, man ihm aber noch nicht ganz folgen kann oder will.

Meine simple Frage daher an die Community:

Wurde jemand selbst mit diesem Problem konfrontiert und konnte es trotzdem mit einem bestimmten Kniff lösen? (Bitte keine Lösung á la "Nimm doch Chipkarte oder Sicherheitsdatei" )

Vielen Dank vorab und Gruß

Schuebli

Also wenn das wirklich immer so geklappt hat, warum geht das bei HBCI-PIN/TAN nicht mehr. Was meldet denn SFIRM bzw. der Bankenrechner wenn Du 2. die gleiche TAN eingibst?

Mir ist allerdings schleierhaft was dann 2 Unterschriften sollen wenn die Überweisungen mit 1 Tan versendet werden können. OK, man hat noch die PIN, aber irgendwas stimmt dann doch nicht.

Läuft das echt so ab bei der DeuBa? Hatte das bis jetzt noch nicht.

Hit

PS: Versuch doch mal die Datei vor dem "Ausführen" bei "Elektronische Unterschrift" zu unterschreiben und dann zu senden.

Hallo,

Ich kann eigentlich nur bestätigen, dass vorher 2xPIN und 1xTAN ausreichend war. Das es da eine Änderung gab, habe ich anscheinend nicht mitbekommen.
Was passiert denn, wenn Du jetzt pro Berechtigtem eine TAN eingibst. Wenn das funktioniert, dann wäre es ja so, wie man es sich vorstellt.

Wäre ja auch denkbar, dass der alte Standard eine TAN zugelassen hat, und der Neue eben nicht.

Gruß
Marc

Sfirm32 geht davon aus, dass zu einem Onlinezugang mittels PIN auch eine TAN gehört, da dies bei allen anderen Banken auch so ist. Wie soll Sfirm32 denn erkennen, dass in diesem Fall wirklich nur eine TAN notwendig ist. Deshalb gibt es auch die Rollenverteilung. Was passiert denn, wenn Du unterschreibst (unter Elektronische Unterschrift) und Du bei beiden Unterschriftsberechtigten die eigene PIN und danach jeweils die gleiche TAN eingibst. Wird das so akzeptiert?

Prüfen kannst Du dies auch unter Datenbanken / HBCI-Banken / Deuba-BLZ anklicken. Hier müssen zwei Nutzer hinterlegt sein (jeder hat jeweils seine eigene Benutzerkennung). Mit dem Abholen der Bankdaten wird die UPD aktualisiert. Also es müsste dann vom Bankrechner zurückgemeldet werden, dass nur zu zweit gezeichnet werden kann. Zu erkennen unter diesem o. g. Menü (HBCI-Banken) / Benutzer ändern / Konten / Ändern / Benutzerspezifische Daten. Prüf das bitte noch mal ab, was hier steht.

Wenn Du zwei Nutzer hast, bekommst Du nach dem Ausgeben der Zahlungen im Fenster Versand DTAUS einen neuen Reiter Elektronische Unterschrift angezeigt. Diesen musst Du anklicken und jeweils auf die entsprechende Person gehen / Rolle zuweisen / Unterschreiben. Hier wirst Du aufgefordert, die PIN+TAN einzugeben. Das musst Du halt für beide Nutzer hinterlegen (mit jeweils eigene PIN + Test gleiche TAN). Was passiert dann? Wird die Zahlung akzeptiert oder abgelehnt.

Der Reiter mit Elektronischer Unterschrift kommt aber wirklich nur, wenn am Bankrechner der Deuba das Konto mit doppelter Unterschrift hinterlegt ist und über Bankdaten abholen, die UPD aktualisiert wird.

@Hit: Die DeuBa hält sich eindeutig nicht an die HBCI-Standard-Spezifikationen. Diese Aussage habe ich auch von Produktverantwortlichen der Firma StarFinanz erhalten.Ich denke, die DeuBa will aktuell das alte System nicht "abschalten" oder umbauen.

@Mafi&Testerin: Diese Option habe ich schon probiert und bin völlig verzweifelt. In den HBCI-Banken habe ich eindeutige A-Berechtigunen bei allen Teilnehmern. Wenn ich die Rollen zugewiesen habe und dann nach Leisten der Unterschriften alles auf die Reise schicken will, bekomme ich den Hinweis, dass die Berechtigungen nicht ausreichend seien. Dies ist völlig egal, ob ich jeweils eine TAN von jedem Berechtigten nehme oder 2x eine TAN des ersten Teilnehmers oder 2x eine TAN des anderen Teilnehmers.

Das Schärfste ist, dass die Zugänge seitens der DeuBa dann aus Sicherheitsgründen gesperrt werden. Technisch gesehen ja auch völlig in Ordnung, aber ich komm absolut nicht damit klar.

Wie schon erwähnt, kommt StarMoney auch nicht damit zurecht. Die Frage, die sich mir stellt: Wie kommen denn Nutzer von DB-Dialog (Multicash) in so einem Fall damit klar? Fragt das Programm schon standardgemäß nur nach einer TAN dann?

Greetings.

Schuebli

Gute Frage aber db-dialog ist nicht Multicash (Hersteller Siemens/SBS, nicht Omikron) und kann HBCI-PIN/TAN sowieso nicht. Somit stellt sich die Frage gar nicht.

Sorry, meinte DB-Direkt

Und warum stellst Du nicht auf HBCI Diskette oder Chipkarte um. Damit stellt sich halt nicht mehr die Eingabe einer 2. TAN, sondern da legst Du entweder die Disk oder die Chipkarten von beiden Benutzern ein.

Das Problem dürfte damit nicht mehr auftreten. Die Umstellung auf HBCI Disk sollte eigentlich auch relativ schnell gehen. Bei dem Chipkartenverfahren brauchst Du ja erst wieder eine Gerätschaft dazu.

Hallo schübli,

im dbdirect mc wir das BTX- Modul gar nicht mit angeboten, daher stellt sich dort das Problem nicht, HBCI+ wird dort ebenfalls nicht unterstützt.
Auf den andern Zugangskanälen der Dt. Bank (Internet, dbdialog) ist/war es ausreichend mit 2xPin, 1xTAN.

Ich vermute ganz stark, das du mit deiner Konstellation keinen Erfolg haben wirst, solang
a) die DB die Schnittstelle nicht anpaßt bzw.
b) solang SFIRM hier keine dementsprechende Option einbaut.

Jo Blacky,

sieht schon fast so aus. Multicash hab ich nur mal am Rande kennengelernt; aber gut zu wissen, dass diese Option dort nicht unterstützt wird.

@Testerin: Hehe, guckstu meinen ersten Eintrag Genau DAS wollte ich gezielt nicht machen. Aber dennoch thx für diese Option.

Wenn noch jemandem was einfällt, freue ich mich über jede Info. Ich quatsche noch ein wenig mit der BIVG und versuche denen die sfprotokoll.mdb und Dialogdateien zur Verfügung zu stellen. Nur ist zweifelhaft, ob die was deswegen an der Prozedur ändern werden

Danke schonmal an alle!

Greetings.

Schuebli

Naja, Schuebli, so lange die BIVG nichts umprogrammiert, wirst Du wohl auf Einzelberechtigung umstellen lassen müssen. Wenn Du dies auch nicht willst, würde ich gar nicht so lang überlegen und einfach auf Disk umstellen lassen?

Was spricht denn dagegen?. So kommt man sicher schneller voran, als dass die BIVG etwas umprogrammiert. Und wenn es so ist, dann wird es frühestens ab der nächsten Version, vielleicht mit der j sp1 oder so.

Also, sei nicht so ein Dickkopf! Manche Probleme lassen sich schneller lösen, wenn man auch mal über den Tellerrand schaut. Meine Meinung, also bitte nicht übelnehmen, ok?

Die Frage ist doch, ob sich das überhaupt umsetzen lässt...

Interessant wäre es doch erst einmal in Erfahrung zu bringen was die HBCI Spezifikationen sagen.

Zuerst:
Bei nicht-Einzelverfügungberechtigung muss es wohl zwingend zwei (oder mehr) in der Kombination A/A oder A/B geben. Beide Verf-Berechtigte besitzen eigene Zugangsdaten.

Analyse:
Übermittelt nun die Deuba in den Parameterdsateien das ein GVV TAN-pflichtig ist, muss wohl auch eine TAN gesendet werden. Dazu dient ein DIPINS Segment in dem beschrieben ist das die EinzelÜW, SammelÜW, EinzelLS, SammelLS (oder sonstwas) eben TAN-pflichtig ist.

Jetzt wird es interessant:
Das DIPINS Segent steht in der BPD, ist also KundenUNabhängig. Es gilt also generell für die Bank, nicht für den einzelnen Beechtigten. Somit muss jeder Berechtigte eine eigene TAN senden, andere Lösungen gibt es im HBCI Standard nicht.

Die Lösung zwei PIN, eine TAN ist m.M. nach über HBCI-PIN/TAN unmöglich.

Das die TAN von Berechtigtem2 im Dialog von Berechtigtem1 (oder andersrum) nicht gültig sein kann dürfte dagegen jedem einleuchten. Die Variante gleiche TAN KANN nicht funktionieren.

Das ganze ist aber nicht verbindlich, ich habe mir das gerade mit den Spezifikationen zur PIN/TAN Erweiterung V1.01 zusammengebastelt.

Hehe, ich alter Grummelbär Wie könnte ich Dir was übelnehmen? Wo Du das doch so nett gesagt hast *rüberzwinker*

Das Problem liegt leider nicht an mir, sondern an den Personen, die im Endeffekt damit arbeiten. Man möchte nicht bei der einen Bank mit Sicherheitsdatei arbeiten und bei der anderen mit PIN/TAN. Den Versuch hatte ich schon erfolglos unternommen, hihi. Und wenn ich es angleichen wollte, scheitert es an der Sparkasse, welche ja leider keine Sicherheitsdatei anbietet (zumindest SI-Sparkassen nicht). Daher habe ich ja so darauf beharrt

Verkauf ihnen FTAM ....

Leute, wie krass ist denn Captain FRAG?
Klingt alles recht plausibel, was Du da sagst. Inwiefern von den Spezifikationen abgewichen werden kann, bleibt fraglich. Ich halte euch auf dem Laufenden, was die BIVG machen kann oder nicht. Zuerst muss ich an die diversen Dateien kommen. Vor Montag wird das aber nix.

FTAM ist auch wieder ne Preisfrage, gell? @i2017377 (--> Deine Personalnummer? *g* Welche Spk verbirgt sich denn hinter 201?)

Gruß

Schuebli

Nicht bei uns ... Kost für Kunden (noch) nix
Abgesehen davon hab ich nen Kunden (Verwaltung-muß sparen), beim auf einer Diskette pro User unsere FTAM-EU uns für die Genossen die HBCI-Signatur liegt. SFirm kanns und der Kunde ist glücklich.


Die erste in RLP (zumindest im Alphabet)

Hm...
Ich glaube meine ersten Gedanken und Schlussfolgerungen lösen sich in Luft auf.
Ich denke man muss das noch weiter aufsplitten, es geht nicht nur um die beiden Verfügungsberechtigten. Einer der beiden (oder sogar ein Dritter) übernimmt im HBCI Dialog die Aufgabe des Senders.
Vergleich: FTAM N (Buchhalter überträgt Datei mit 2 A-EU der Geschäftsführer
Bei HBCI muss aber IMHO der Sender auch gleichzeitig unterschreiben, so fein wie bei FTAM ist es nun doch nicht....

Zurück zum Thema:
Für den Sender gilt nun, das der Auftrag TAN-Pflichtig ist. Für ihn gilt das was in der BPD steht, nämlich die TAN Pflicht aus dem DIPINS Segment. Ob es noch irgendwo eine Anzahl gibt muss ich nochmal recherchieren. Das kann eigentlich nur in der UPD stehen, schliesslich kann man technisch für einen Berechtigten bei Konto1 E-Vollmacht vergeben, bei Konto2 aber nur B.

Das ist aber was für morgen...

/edit:
Jep, im HIUPD Segment steht für jeden Signaturpflichtigen GVV auch die Anzahl der benötigten Signaturen. Was bei PIN/TAN nun genau die Signatur ausmacht ist die Frage... Streng gibt es ja gar keine. Es gibt nur den Ersatz über PIN/TAN, die Frage ist nun ob die TAN die Signatur darstellt oder reicht es wenn der User sich über die PIN einfach nur mit-anmeldet?

4-Augen-Prinzip bei der Deutschen Bank:
Bei der Deutschen Bank werden pro Zahlung zwei PIN und eine TAN eingegeben.
Teilnehmer A gibt seine PIN und eine TAN der Liste von Teilnehmer B ein, dann gibt Teilnehmer B seine PIN und die selbe TAN ein, die von Teilnehmer A eingegeben wurde.


=> Ausschnitt Sfirm-Handbuch.

Jo thx, Frag. Aber genau das ist das Problem. Teilnehmer B sperrt sich jetzt, wenn er die TAN von Teilnehmer A eingibt. Leider kann ich jetzt nicht mehr testen, weil die Kunden ihren neuen Router/Server aufs classicgate konfiguriert haben. Mit anderen Worten: Sie arbeiten weiter mit BTX bis zum Umfallen. Irgendwann wird das Problem aber wieder auftreten. Erst dann können wir weiter reden

Ich würde mir darüber gar nicht so einen Kopf machen.
Solange anscheinend nicht mal die Deuba ihre eigene Logik bei Mehfachkompetenz über HBCI-PIN/TAN versatnden hat und erläutern / von BTX abgrenzen kann....