[gnucash-de] Pin / Tan

[Bernhard Rietzl]

Christian Stimming schrieb:

>
> Man unterscheide zwei Fälle:
>
> 1. Pin/Tan ohne HBCI, sondern nur über Webseiten. Vorteil: Fast jede 
> Bank bietet es an. Nachteil: Überhaupt kein standarisierter Zugang; 
> jede Bank müsste praktisch ihre eigene online-banking-software 
> schreiben. Überhaupt keine Spezifikation erhältlich, und selbst wenn, 
> dann wäre sie für jede Bank eine andere. Status Gnucash: Dies wird 
> nicht unterstützt und wird auch nie unterstützt werden.
>
> 2. Pin/Tan über HBCI. Vorteil: Manche Banken (Sparkassen) bieten es 
> an. Etwas einfachere Einrichtung als Schlüsseldatei-HBCI. 
> HBCI-Standard öffentlich erhältlich. Nachteil: Geringere Sicherheit 
> als bei Chipkarten-/Schlüsseldatei-HBCI. Status GnuCash (via 
> OpenHBCI): Wird bisher nicht unterstützt, aber wie Martin Preuß 
> bereits schrieb, ist er dabei, die Unterstützung in OpenHBCI 
> einzubauen. Vielleicht in 2-3 Monaten zu erwarten.

Es sind beim PIN/TAN-Verfahren 4 Fälle:

1. PIN/TAN über die Web-Schnittstelle
Dies ist nur für einen menschlichen Benutzer gedacht, nicht für die 
Nutzung durch ein Programm. Vorteil: wie erwähnt bietet es jede Bank an, 
sie ist providerunabhängig. Wer hier versucht Schnittstellen zu 
schreiben, ist m.M. nach wahnsinnig, obwohl es ein Projekt gibt, das bei 
einer Bank die Webschnittstelle nutzen kann.

2. PIN/TAN über T-Online
Der STANDARD, wenn es  um ZV-Programme im Zusammenhang mit  PIN/TAN 
geht. Vorteil: Fast jede Bank bietet es an, Nachteil:  Man ist an 
T-Online als Internetprovider gebunden, da das sog.  Classic Gateway 
(BTX-Seiten zum Datenaustausch) von T-Online benutzt wird. Die 
Schnittstelle wurde von fun communications, Karlsruhe entwickelt und 
kann dort gegen Bares lizensiert werden. Die Banken wenden sich von 
diesem Verfahren mittelfristig ab, weil die Telekomiker sich den Betrieb 
der alten Infrastruktur vergolden lassen.

3. PIN/TAN über Sonderlösungen
Die Sonderlösungen basieren meist auf ähnlichen Techniken wie das 
Classic Gateway in 2. oder auf  SSL-basierenden Verfahren, sind aber 
nicht an T-Online gebunden, also providerunabhängig. Der Nachteil dieser 
Lösungen ist, daß sie nur für einzelne Banken oder Bankgruppen taugen, 
da deren Rechenzentren die entsprechenden Server bereitstellen müssen.
Beispiele hierfür sind der sog. CAT-Verfahren der Genobanken, die an die 
FIDUCIA, Karlsruhe angebunden sind. Hier erfolgt  die Datenübertragung  
auf  Übertragungsseiten  wie  unter 2.. Das  Verfahren stammt ebenso von 
fun communications und kann dort lizensiert werden. ZV-Software, die das 
Verfahren benutzt: VR-NetWorld Software
Ein weiteres Beispiel  ist die  Lösung der Firma StarFinanz, Hamburg. 
Hier wird wohl ein SSL-ähnliches Verfahren benutzt. Clientsoftware ist 
StarMoney, der Server dazu ist der StarFinanz Server, manche Sparkassen 
benutzen dieses Verfahren.

4. PIN/TAN über HBCI.
Der zukünftige (und der ist bald da!) STANDARD.Vorteil: 
Providerunabhängig, offene Schnittstelle, einfache Einrichtung dadurch 
sehr leichte Migration der bestehenden Kunden.  (bei einer bestehen 
ZV-Software reicht ein Online-Update der Software, um vom Verfahren 2. 
oder 3. darauf umzuschalten.
Die Genossenschaftsbanken werden mit der Verfügbarkeit der VR-NetWorld 
Software 2.0 ab April 2004 komplett auf dieses Verfahren migrieren 
können, einzelne Sparkassen bieten das Verfahren schon an, Grossbanken 
und Postbank werden auch nachziehen, bei Direktbanken kann ich mir 
verstellen, daß die Einführung auf wenig Interesse stösst, da sie sich 
durch eine programmbediente Schnittstelle die Möglichkeit 1. beschneiden 
und evtl Cross-Selling  behindern würden. So wurde bei der Advance ja 
auch schon HBCI gekippt, andere Direktbanken bieten außer 1. und evtl. 
2. nichts an.

Bernhard Rietzl