Wenn Du mal hier mit anderen Sparkassen und der HaSpa vergleichst, wirst Du feststellen, dass die HaSpa da ihr eigenes Süppchen kocht. Die arbeiten nämlich nicht mit dem üblichen Dienstleister der Sparkassen, der Finanz Informatik zusammen sondern betreiben ein eigenes Rechenzentrum. Daher können natürlich auch Unterschiede im Angebot resultieren. Ich würde mir an Deiner Stelle eine andere Bank suchen die auch entsprechende Sicherheitsverfahren anbietet. Die HaSpa will nicht, dann willst Du auch nicht ...
Wenn Du mal hier mit anderen Sparkassen und der HaSpa vergleichst, wirst Du feststellen, dass die HaSpa da ihr eigenes Süppchen kocht. Die arbeiten nämlich nicht mit dem üblichen Dienstleister der Sparkassen, der Finanz Informatik zusammen sondern betreiben ein eigenes Rechenzentrum. Daher können natürlich auch Unterschiede im Angebot resultieren. Ich würde mir an Deiner Stelle eine andere Bank suchen die auch entsprechende Sicherheitsverfahren anbietet. Die HaSpa will nicht, dann willst Du auch nicht ...
Supertipp die Seite, danke ! Lustigerweise steht für die Haspa dort FinTS V3.0 als PIN/TAN-Version drin...
Also ich brauche auf jeden Fall etwas, was ich mit meiner StarMoney-Software nutzen kann, direktes online-banking möchte ich nicht.
Und das solltest Du dann im Star Money Forum weiter diskutieren, da wir hier nicht wissen, was Deine Software unterstützt
Aber HBCI 2.2. Das verstehe, wer will. Logisch ist das nicht.
Aber HBCI 2.2. Das verstehe, wer will. Logisch ist das nicht.
Haspa eben....
Allen hier vielen Dank für die hilfreichen Tipps !
Supertipp die Seite, danke ! Lustigerweise steht für die Haspa dort FinTS V3.0 als PIN/TAN-Version drin.
Na ja, hier kommt es auch immer darauf an, in wieweit die Daten in dieser Datenbank gepflegt sind... 
Wenn da Dinge in Bewegung sind wäre ich immer vorsichtig.
Moin,
auf die Gefahr hin das mich einige als Klugsch... bezeichnen werden 
, möchte ich doch mal ein paar Anmerkungen zu den Begrifflichkeiten zum Besten geben:
Die Verwirrung entsteht meistens dadurch, dass die Begriffe HBCI und FinTS vermischt werden.
Bei HBCI handelte es sich ursprünglich (1998) um eine Schnittstellenspezifikation/ein Protokoll das festlegt wie Bankingsoftware-Produkte und Bankserver via Internet kommunizieren.
Da seinerzeit die SSL-Verschlüsselung nicht ausreichend sicher war, musste zur Absicherung der Dialoge ein Sicherungsverfahren entwickelt werden das zum einen die Auftragsdaten verschlüsselt und sicher stellt das nur der jeweilige Partner diese auch wieder entschlüsseln kann, und zum anderen das der Empfänger anhand einer elektronischen Signatur prüfen kann, ob die Nachricht wirklich von einem bestimmten Absender stammt und unverändert ist.
Die Schlüsseldaten waren kundenindividuell und als Medium zur Speicherung der Schlüsseldaten konnte entweder eine Sicherungsdatei auf Diskette/USB-Stick verwendet werden oder eine spezielle Chipkarte und Kartenleser.
Da es nur dieses eine Sicherungsverfahren gab, wurde der Begriff "HBCI" synonym für die Schnittstellenspezifikation und das Sicherungsverfahren benutzt.
So um und bei 2002 war die SSL-Verschlüsselung so weit fortgeschritten dass sie für die reine Transportverschlüsselung von Aufträgen problemlos genutzt werden konnte und damit war der Weg frei für die einfachere Variante die Banking-Aufträge mit PIN und TAN abzusichern.
Inhaltlich wurde immer noch das 1998 spezifizierte Übertragungsprotokoll genutzt (jetzt in der Version 2.2), aber die Absicherung erfolgte anstatt mit Schlüsseldatei (HBCI) über SSL sowie die Eingabe einer PIN und bei Transaktionen einer TAN.
Das ganze lief Anfangs unter der Bezeichnung HBCI+ oder HBCI-PIN/TAN.
Im November 2002 wurde die Spezifikation in der Version 3.0 veröffentlicht und hier wurde dann getrennt nach dem reinen Übertragungsprotokoll/der Schnittstellenspezifikation FinTS und den Sicherungsverfahren HBCI (mit Schlüsseldatei oder Chipkarte) und Sicherungsverfahren PIN/TAN. Seitdem heißt esoffiziell eben auch nicht mehr HBCI-Spezifikation, sondern FinTS-Spezifikation.
Das Sicherungsverfahren HBCI in der von der Haspa verwendeten Form (RDH-1 mit Schlüsseldatei oder Chipkarte) durfte nur bis zur FinTS-Version 2.2 verwendet werden, höhere HBCI-Verfahren sowie das Sicherungsverfahren PIN/TAN ab der FinTS-Version 3.0.
Deswegen auf der Seite "https://www.hbci-zka.de/institute/institut_auswahl.htm" für die Haspa auch die unterschiedlichen Angaben zu den Versionen.
Das was die Haspa jetzt abkündigt ist das Sicherungsverfahren HBCI (RDH-1 mit Schlüsseldatei oder Chipkarte) .
Es wird weiterhin das Onlinebanking via FinTS geben, aber halt nur noch mit den PIN und den TAN-Verfahren chipTAN, smsTAN und pushTAN.
Das funktioniert i.d.R. mit allen Softwareprodukten mit denen auch das Sicherungsverfahren HBCI genutzt werden kann, sofern es sich um aktuelle Versionen handelt.
Beim derzeitig bei der Haspa verwendeten Sicherungsverfahren HBCI-RDH-1 (und im übrigen auch beim alten Chipkarten-Verfahren der anderen Sparkassen) können diverse Aufträge in den Ausgangskorb (oder so ähnlich) eingestellt werden und mit einer einzigen Aktion verschlüsselt und signiert werden und genau das ist nach der neuen Richtlinie PSD II ab 13.01.2018 nicht mehr zulässig. Dann muss jeder einzelne Auftrag vom Kunden separat bestätigt werden (auf jeden Fall jede Transaktion wie z.B. Überweisungen, und ggf. sogar reine Abfrageaufträge).
Diese Anforderung wird beim Sicherungsverfahren PIN/TAN quasi automatisch erfüllt (zumindest für Transaktionen), für das Sicherungsverfahren HBCI aber nur mit der so genannten "Fortgeschrittenen elektronischen Signatur" (FeS) mit all ihren oben schon erläuterten Herausforderungen.
Da die Haspa, wie hier schon erwähnt, in absehbarer Zeit zur Finanzinformatik "wandert" erfolgt keine Realisierung der FeS mehr. Ob nach der Umstellung dann von der Haspa die FeS angeboten wird (die Finanzinformatik kann das grundsätzlich) und ob die Sparkassen das überhaupt noch anbieten steht in den Sternen (so die Info meines Beraters)
Gruß Potz
Nach Aussage meines online-Banking Beraters, justamente gerade teleonisch kontaktiert (RZ FI-Münster), stimmt das so nicht. Da heißt es, dass die derzeitige Chipkarte noch bis 2020 im Einsatz seien wird und ob dann eingestellt ist noch nicht klar.
Da scheint es noch Unsicherheiten im Markt zu geben.
Wenn jemand mal zufälligerweise die Stelle in den Regelungen kennt oder findet und hier mit Quelle nennt, die diese Ansprüche, wie sie Potzblitz9 beschreibt, erläutert, wäre das nicht schlecht.
Falk
Nein. Für das Verfahren mit der HBCI-Chip(Schlüssel)karte bekommst Du eine extra Karte vom Zahlungsdienstleister. Eine Signaturkarte für das Banking.
Nein. Für das Verfahren mit der HBCI-Chip(Schlüssel)karte bekommst Du eine extra Karte vom Zahlungsdienstleister. Eine Signaturkarte für das Banking.
Ah ok, statt USB-Stick dann praktisch eine Signaturkarte (+ Lesegerät).
Habe die Bank nochmal angeschrieben und warte ab was da kommt...
Wobei aus Sicherheitsgründen ein Kartenlesegerät mindestens der Klasse 2 (hat die Tastatur eingebaut) angeraten ist. Klasse 3 hat dann auch noch ein Display.
Wobei aus Sicherheitsgründen ein Kartenlesegerät mindestens der Klasse 2 (hat die Tastatur eingebaut) angeraten ist. Klasse 3 hat dann auch noch ein Display.
Ok, wo bekommt man sowas günstig ?
Ok, wo bekommt man sowas günstig ?
Diese Geräte haben nun mal ihren Preis. Aber Du kannst die üblichen Preissuchmaschinen nutzen.
Hallo,
Nach Aussage meines online-Banking Beraters, justamente gerade teleonisch kontaktiert (RZ FI-Münster), stimmt das so nicht. Da heißt es, dass die derzeitige Chipkarte noch bis 2020 im Einsatz seien wird und ob dann eingestellt ist noch nicht klar.
Wie weiter oben schon gesagt wurde, hat die HASPA ein eigenes Rechenzentrum, hängt also nicht mit dem Sparkassenrechenzentrum Finanz Informatik zusammen. Woher also will Dein FI-Berater wissen, was die Hamburger für Entscheidungen treffen?
Wenn jemand mal zufälligerweise die Stelle in den Regelungen kennt oder findet und hier mit Quelle nennt, die diese Ansprüche, wie sie Potzblitz9 beschreibt, erläutert, wäre das nicht schlecht.
Moin,
wem es Spaß macht 
dem sei die Umsetzungsrichtlinie zur EU-Directive 2015/2366 (PSD II) der EBA ans Herz gelegt.
U.a. findet man hier In CHAPTER II - Article 5 auf der Seite 13 die Anforderung, dass (frei übersetzt) die Summe der Transaktion sowie Angaben zum Empfänger Bestandteil des Verifizierungscodes sein müssen und das der Zahler die Möglichkeit haben muss diese Angaben vor dem absenden der Transaktion zu überprüfen.
Das ist nur ein winziger Teil der gesamten Richtlinie, aber genau der kritische Punkt.
Gruß Potz
das der Zahler die Möglichkeit haben muss diese Angaben vor dem absenden der Transaktion zu überprüfen.
genau das ist aber der Casus cnactus! Er muss die Möglichkeit haben, es darf ihm aber nicht vorgeschrieben werden, diese auch zu nutzen. Aber genau hier argumentieren die Banken sehr ungenau, da sie behaupten, der Zahler müsse vorher verifizieren.
Ja, mit den Auslegungen ist das immer so eine Sache.
Die EU macht gewisse Vorgaben, die wie so oft Interpretationsspielräume zulassen.
Im Gesetzentwurf der Bundesregierung wurde das dann wie folgt formuliert:
§ 55
Starke Kundenauthentifizierung
(1) Der Zahlungsdienstleister ist verpflichtet, eine starke Kundenauthentifizierung zu verlangen, wenn der Zahler
1. online auf sein Zahlungskonto zugreift;
2. einen elektronischen Zahlungsvorgang auslöst;
3. über einen Fernzugang eine Handlung vornimmt, die das Risiko eines Betrugs im Zahlungsverkehr oder anderen Missbrauchs beinhaltet.
Ein Zahlungsdienstleister muss im Fall des Satzes 1 über angemessene Sicherheitsvorkehrungen verfügen, um die Vertraulichkeit und die Integrität der personalisierten Sicherheitsmerkmale der Zahlungsdienstnutzer zu schützen.
(2) Handelt es sich bei dem elektronischen Zahlungsvorgang nach Absatz 1 Satz 1 Nummer 2 um einen elektronischen Fernzahlungsvorgang, hat der Zahlungsdienstleister eine starke Kundenauthentifizierung zu verlangen, die Elemente umfasst, die den Zahlungsvorgang dynamisch mit einem bestimmten Betrag und einem bestimmten Zahlungsempfänger verknüpfen.
(3) Absatz 1 Satz 2 und Absatz 2 gelten auch, wenn Zahlungen über einen Zahlungsauslösedienstleister ausgelöst werden. Absatz 1 gilt auch, wenn die Informationen über einen Kontoinformationsdienstleister angefordert werden.
(4) Der kontoführende Zahlungsdienstleister hat es dem Zahlungsauslösedienstleister und dem Kontoinformationsdienstleister zu gestatten, sich auf die Authentifizierungsverfahren zu stützen, die er dem Zahlungsdienstnutzer gemäß Absatz 1 sowie, in Fällen, in denen ein Zahlungsauslösedienstleister beteiligt ist, darüber hinaus gemäß Absatz 2 bereitstellt.
Wenn man den Satz (2) streng auslegt könnte daraus durchaus der Zwang abgeleitet werden.
Im nächsten Schritt sind dann die Bankenverbände dran mit ihrer Auslegung des Gesetzes - mal sehen welcher Verband das wie auslegt. Aber ich denke schon das da in den nächsten Monaten noch die eine oder andere Überaschung auf die Onlinebanker zukommen wird.
Gruß Potz
Aber das macht MG ja auch, den es listet ja die Transaktionen im Protoholl auf (speicherbar!). Überweisungen können vor der Verarbeitung im Onlinecenter eingesehen werden. Zum anderen wird ein Log geschrieben. Die daten, die versendet werden kann sowieso niemand sehen, sonst müssten sie "auf der Leitung mitgeschnitten werden". Eine Gewisse Art der Manipulationsmöglichkeit besteht immer.
