[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Online-banking via Inet



Am Fri, den 17 Apr 1998 um 01:34:42 +0200 schrieb:
> Uwe Brockmann wrote:
> > Warum nicht folgendes:
> > [Lynx, Perl, expect, ...]
> 
> Hmmm... vielleicht, weil "lynx" und "expect" da ueberfluessig sind,
> da Perl (mit LWP[ng]) das alles auch schon selbst kann? :-)

Danke fuer den Hinweis auf libwww-perl (LWP[ng]). Damit duerfte sich
die von mir vorgeschlagene Emulation von E-mail Banking mit SSL-Banking 
eleganter verwirklichen lassen als mit lynx und expect. Nur mit Perl
alleine geht es allerdings nicht, da es keine Perl-Implementation von
SSL gibt. libwww-perl loest das Problem durch Aufruf von SSLeay Binaer-
code. Man muesste also ausser Perl und libwww-perl auch SSLeay
installiert haben.

Uwe Brockmann:
> > Erforderlich sind hierzu:
> > [...]
> >         - Eintippen von PIN und TANs, jedesmal wenn die Bank einem neue TANs
> >           schickt muesste man diese alle Eintippen, so dass sie fuer Perl-
> >           Skripte zugaenglich sind
> 
> *Peng*!
> 
> TAN-Nummern sollten *selbstverstaendlich* erst
> kurz vor der Benutzung eingetippt werden.

Berechtigter Einwand. Die Speicherung der TANs auf Festplatte statt nur
auf Papier birgt Sicherheitsrisiken. Ich wuerde dies nur auf einem
Rechner machen, ueber den ich volle physische Kontrolle habe. Ich bin
mir noch nicht ganz darueber im Klaren, was man machen muss, um eine
TAN-Datei wirksam gegen einen Angriff von aussen ueber die SLIP/PPP-
Verbindung zu schuetzen. Vermutlich kommt man um die Installation eines
Firewalls auf einem zweiten Rechner nicht herum.

Eine TAN-Datei auf Festplatte waere bei einem Einbruchsdiebstahl evtl.
staerker gefaehrdet als die TAN-Liste auf Papier. Das Risiko muesste man
in Kauf nehmen oder die Datei verschluesseln was nicht ganz einfach
sicher zu machen ist. Bei Veraeusserung des Rechners muesste man ausser-
dem die Festplatte wirksam loeschen.

> > Nicht erforderlich sind
> > [...]
> >         - "Buntiklick" Software
> > 
> > Die Tatsache, dass Lynx direkte Cursor-Adressierung verwendet, duerfte
> > das Schreiben eines expect-Skriptes erschweren aber nicht verhindern.
> 
> Mit der Dir (m.E. zu Unrecht) gescholtene "Buntiklicki"-Software
> kann man komplexe Prozesse so praesentieren, dass sie auch ein
> (bekannterweise nur beschraenkt aufnahmefaehiges) menschliches
> Gehirn zuverlaessig verarbeiten kann. Ich sehe daher keinen
> sinnvollen Grund, warum man im Privatbereich (=wenige Transaktionen)
> auf ein GUI verzichten sollte. (Sag jetzt nicht, dass Du die von
> Dir vorgeschlagene skript-/kommandozeilenbasierte Technik selbst
> wirklich durchschaust - Dein unnoetig hochkomplexer Vorschlag
> (lynx, Cursorpositionen parsen [wieso nicht Perl, oder "lynx -dump"?])
> laesst eher vermuten, dass es Dir da genauso wie den meisten
> Windows-Benutzern geht, dass naemlich UNIX fuer Endbenutzer
> immer noch viel zu kompliziert ist.

Ich habe gar nichts gegen "Buntiklick" Software. Mein Vorschlag zur
Emulation von E-mail Banking auf Benutzerseite mit vorhandenen Standard-
tools auf Basis von SSL-Banking sollte die verschiedenen Behauptungen
anderer widerlegen, dass man fuer E-mail Banking besondere Protokolle,
CORBA, VMS, Financial EDI oder auch nur die Kooperation der Bank benoe-
tigt.

Ausserdem wollte ich zeigen, wie man das von Hartmut Pilch geforderte
E-mail Banking System ohne "virtuelle Warteschlangen" sofort und mit
geringem Aufwand, wenn auch nur durch Emulation, realisieren kann. Den
Begriff "Buntiklick", der glaube ich von Hartmut kam, habe ich nur in
diesem Zusammenhang verwendet.

Ich benutze zur Zeit das Postbank SSL-Banking mit Netscape Navigator mit
"Freude und Zuversicht" und waere selber nicht bereit, auf ein E-mail
Banking System (einschliesslich des von mir vorgeschlagenen, emulierten)
umzusteigen.

Die "-dump"-Option von lynx duerfte mit den SSL-Patches inkompatibel
sein, da sie zum sofortigen Verlassen von lynx nach dump der ersten
eingelesenen Datei fuehrt und somit das Einlesen weiterer Dateien ueber
das Internet im Rahmen eines SSL-Dialoges verhindert.

> Zu der ganzen E-Mail-Idee: was waere der Vorteil davon, auf das
> direkte Feedback ueber den Verlauf der Transaktion zu verzichten?

Keiner.

> Wenn man nicht gerade eine Standleitung hat, muesste man zum
> Kontrollieren der Antwort/Bestaetigung ja trotzdem ein weiteres
> Mal anrufen, was u.U. (je nach Gebuehrentakt) sogar teurer
> werden koennte.

Stimmt.

Einen Teil meines Vorschlages, naemlich das Pollen des Bankservers
bei jedem Einloggen zwecks Emulation einer e-mail-Benachrichtigung des
Kunden nach jeder Buchung, wuerde ich allerdings gerne verwirklicht
sehen und auch benutzen.

Es wuerde mir schon reichen, wenn man damit nur herausfinden koennte,
dass sich etwas geaendert hat und fuer Detailinformationen anschliessend
manuelles SSL-Banking bemuehen muesste. (Diese Einschraenkung wuerde das
benoetigte Perl-Skript vereinfachen.)

Die Beschraenkung auf E-mail-Benachrichtigungsemulation haette auch
einen Sicherheitsvorteil, da sie als rein "lesender" Kontozugriff keine
TANs sondern nur die PIN erfordert.

Uwe Brockmann, uwe@netcom.com