Moin,
On Mittwoch, 19. August 2009, Marcel Naziri wrote:
> Also sprach Martin Preuss am Mittwoch 19 August 2009:
> > On Mittwoch, 19. August 2009, Marcel Naziri wrote:
> > > Also sprach Micha Lenk am Mittwoch 19 August 2009:
[...]
> Da finde ich es in der Tat erstaunlich, dass sowohl gnucash als auch
> qbankmanager bei PIN/TAN das Zertifikat nicht speichern, bei DDV jedoch
> sehr wohl. Oder habe ich die Zertifikate für die DDV-Accounts noch irgendwo
> auf der Platte liegen. Diese Zugäng sind sehr alt.
[...]
QBankManager speichert sie ja, aber eben erst in der SVN-Version. Es gab schon
lange keine neue Release von QBankManager mehr...
[...]
> Es wird aber schon geprüft, dass es sich um das einst akzeptierte
> Zertifikat handelt und bei einer Abweichung gibt es dann wieder die Frage
> oder einen Hinweis, oder?
[...]
Natuerlich, siehe unten.
[...]
> Handelt es sich eigentlich um übliche SSL-Zertifikate?
> In .aqbanking/settings/apps/qbankmanager.conf fand ich unter kbanking
> diesen Abschnitt
>
> certs {
> int EEA10A9586068996A343D36F4FDA584D="0"
[...]
Hier werden nicht die Zertifikate gespeichert, sondern es wird ein Hash
gebildet aus Fingerprint des Zertifikates sowie der Meldung, die dem Benutzer
praesentiert wurde, als er das Zertifikat bestaetigt hatte.
Das bedeutet, dass immer dann nachgefragt wird, wenn
- sich das Zertifikat selbst aendert (dann gibt es einen neuen Fingerprint)
- sich die Meldung aendert (z.B. wenn weil das Zertifikat inzwischen
abgelaufen ist).
Die Philosophie dahinter ist halt, dass der Benutzer nicht auf ewig ein
Zertifikat akzeptiert, sondern bei einer Statusaenderung des Zertifikates
ebenfalls noch einmal gefragt wird.
[...]
> Du sagst, dass die Applikation für das Speichern der Zertfikate zuständig
> ist. Heißt das, dass sie dann auch jeweils einen eigenen Speichercontainer
> dafür haben müssen. Ich wäre davon ausgegangen, dass so was zentral mit
> einem aqbanking-Benutzer gespeichert wird und aqbanking dafür Methoden zum
> Auslesen, Speichern und Validieren bereitstellt. Gerade letzteres ist
> sicherheitsrelevant und sollte nicht von jeder Anwendung aufs Neue
> implementiert werden.
[...]
Habe ich ja geschrieben: AqBanking bietet dazu Funktionen an, die von der
Anwendung genutzt werden koennen. QBankManager und KMyMoney nutzen sie, weil
sie es koennen. GnuCash kann es leider nicht, weil man hier einen voellig
anderen Weg bei der Implementierung der GWEN_GUI-Callbacks gegangen ist, der
es leider nicht ermoeglicht, das Angebot der Zertifikatsverwaltung durch
AqBanking ohne groessere Aenderungen anzunehmen :-/
Wie gesagt: Die meisten Anwendungen teilen sich inzwischen die Informationen
ueber die bestaetigten und akzeptierten Zertifikate. Aber es ist immer noch
eine Entscheidung der Anwendung (bzw. die der Programmierer), ob sie diese
Informationen verwendet.
Ich habe mit den verschiedenen Implementierungen von GWEN_GUI Angebote
gemacht, die aber nicht von den Anwendungen angenommen werden *muessen*.
Verstaendlicherweise nehmen meine Anwendungen - und auch KMyMoney, welches
unser QBanking-Frontend verwendet - dieses Angebot an ;-)
Gruss
Martin
--
"Things are only impossible until they're not"
Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
