Keine Empfehlung für die comdirect REST API

[raupach]

Hallo zusammen,

Ich finde es sehr postiv, dass es eine umfangreiche Dokumentation und Beispiele zur comdirect REST API gibt. Mir ist durchaus bewußt, dass es im Bankenumfeld regulatorische und technische Hürden gibt, die die Bereitstellung einer von PSD2 geforderte Schnittstelle erschweren. Allerding ist die API in ihrer aktuellen Form nicht mit guten Gewissens in Desktop, Web, Mobile oder M2M integrierbar. 

Folgende Punkte halte ich für bedenklich:

Die comdirect REST API verwendet Begrifflichkeiten von OAuth 2.0 implementiert den Standard allerdings nicht. Mit OAuth 2.0 sollen Dritt-Applikation (clients) einen kontrollierten Zugang auf Resourcen des Inhabers erhalten. Dabei soll der client niemals den Inhaber (resource owner) imitieren. Das geht nur, wenn die eigentlichen Inhaber Zugangsdaten (user credentials) nicht der Dritt-Applikation zugänglich gemacht werden.

Bei der Registrierung eines clients, comdirect nennt das hier Entwicklerzugang, wird eine client_id und ein client_secret erzeugt. Mehr nicht. Es fehlt die callback_url. Ohne callback_url keinen Authorization Code Flow. Dabei ist der Authorization Code Flow eigentlich der empfohlene Weg um an ein Access Token zu gelangen. Zudem ist es nicht möglich mehrere clients zu erstellen, sondern man ist auf eine client_id festgelegt.

Stattdessen werden Access Tokens mit dem Resource Owner Password Credentials Flow in Kombination mit dem von der comdirect entwickeltem CD Secondary Flow erzeugt.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4

The resource owner password credentials grant MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client.  Even if the client is benign, this results in an increased attack surface (credentials canleak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.

Es fällt auf, dass beim Resource Owner Password Credentials Flow (siehe Dokumentation 2.1) der scope nicht vorhanden ist. Ohne scope heißt hier Vollzugriff auf alle Resourcen. Der resource owner hat keine Möglichkeiten den client einzuschränken.

Der CD Secondary Flow versucht die Unzulänglichkeiten auszumerzen. Das eigentlich Access Token aus Schritt 2.1 wird per 2FA z.B. mit der PhotoTan umständlich neu erzeugt und überschrieben. Die Session-Tan macht aus dem alten Access Token ein neues Access Token, dass alle Befugnisse einer Session-Tan umfasst. In der photoTAN App mit Push-Funktion wird eine Freigabe für "Login Persönlicher Bereich" verlangt. Es wird dem Benutzer der App nicht angezeigt, dass die TAN für eine Dritt-Applikation erstellt wurde. Die client_id fehlt.

Das Session-Objekt im HTTP-Header x-http-request-info erfüllt keine nenneswerte Funktion und kann mit einer konstanten Zeichenfolge ersetzt werden. Das Session-Objekt ist kein Schutz gegen eine Replay Attack. Den Session identifier hätte man bereits im Response von Schritt 2.1 übersenden können.

Viele Grüße

[raupach]

@SMT_Jan-Ove 

Es gibt keinen Grund für kurze Refresh Tokens. Access Tokens ist kurz, Refresh Token ist lang. Per Definition. Deswegen einigt man sich auf Standards und hält sich dran. Andere Banken können das schließlich auch: https://developer.db.com/apidocumentation/oauthflows/overviewgranttypes

Das Ihr hohen Sicherheitsstandards verpflichet seid weiß ich. Find ich gut. Mit einem Refresh Token allein kann ein Angreifer nichts machen, dazu benötigt er im Refresh Token Flow noch Client Credentials. Die hat er eigentlich nicht. Es sei denn ich schicke ihm die ihm per Cron Job alle 5 Minuten auf Euren Auth Server, zusammen mit client_id, client_secret,  Kundennummer und PIN. 

Und weil das Thema Cronjob aufkam. Cronjob auf dem Handy? Wirklich? Oder in einer Webanwendung? Die ich übrigens nicht sicher erstellen kann, weil mir von Euch der Authorization Code Flow fehlt, aber gehen wir mal davon aus, ihr hättet den und ich hab 1000 Kunden auf meiner Webseite. Wollte Ihr wirklich, dass mein Host Euch alle paar Minuten 1000 Anfragen schickt? Klingt das praktikabel?

Ich versuch hier nur gutgemeintes Feedback zu geben 🙂

[SMT_Jan-Ove]

Hallo @raupach,

danke nochmal für dein Feedback, die zuständige Fachabteilung ist natürlich darüber informiert und wird deine Anmerkungen für Weiterentwicklungen berücksichtigen.

Bitte bedenke, dass die dir zur Verfügung gestellten Daten gemäß Nutzungsbedingungen nicht für die Erstellung solcher Anwendungen zugelassen sind, sondern nur für die eigenen Konten und Depots. Bei Interesse an einem geschäftlichen Kontakt und dem Hosting einer Anwendung für andere Kunden wende dich gerne an die Unternehmenskommunikation der comdirect.

Beste Grüße

Jan-Ove

[raupach]

Alles klar. Dann weiß ich Bescheid.

[CommunityDev]

Hallo comdirect,

ein kurzer Refresh-Token stellt ein Risiko-Problem dar. Das ist ein altes Problem:

Bei dem Beispiel unten ist der Siegelring der Refresh-Token und der Abdruck auf dem Schreiben der Access-Token.

Der König hat einen Siegelring, mit dem er Schreiben signiert, die mit einem Boten dem Emfänger überbracht werden. Bei diesem Beispiel kann der Access-Token nur ein einziges Mal verwendet werden.

Muss der König nun aber mehrmals im Monat zum Empfänger und den Siegelring erneuern, entsteht ein höheres Sicherheitsrisiko, als die Laufzeit vom Siegelring über diesen Monat hinaus zu verlängern. Denn die Erneuerung erfordert den kurzzeitigen Zugriff auf Merkmale des Königs (Veröffentlichung), welche zur Austellung eines neuen Siegelringes benötigt werden. Diese Merkmale sind sonst nur alle paar Wochen oder alle paar Monate zugänglich und nicht alle 10-20 Minuten.

Oder anders: Zur Ausstellung von einem Refresh-Token muss auf den Authentification Server zugegriffen werden, was mehr sensible Daten erfordert, als der Zugriff auf eine Resource nur mit dem Access-Token. Die Sicherheit entsteht hierbei durch die Reduktion der Häufigkeit beim Austausch sensibler Daten.

Ja, ich weiß, dass ein Refresh-Token mächtig ist. Die Daten zur Ausstellung von einem Refresh-Token sind aber mind. genauso mächtig. Es muss die Häufigkeit der Übertragung dieser Daten über das Netz reduziert werden, bzw. das ist die Idee dahinter, welche von der comdirect Bank ausgehebelt wird.

Ein Refresh-Token sollte zumindest eine Gültigkeit von einer Woche haben.

Jens

[CommunityDev]

Außerdem kann ich weiterhin, wie bisher, ohne die Generierung einer TAN mit einer Maschine das HTML Interface nutzen und die Kontostände ermitteln.

Wenn die Session-TAN, bzw. cd-secondary die Sicherheit erhöhen soll, warum steht dann die Pforte HTML so weit offen?

[CommunityDev]

Und warum wird die Sicherheit ausgehebelt, indem nochmals username und password bei 2.1 mitgegeben werden müssen? Die Authentifizierung hat doch schon stattgefunden, als der Benutzer sich im comdirect Portal angemeldet hatte.

Normalerweise definiert ein Benutzer den Scope im Portal je Client. So kann ein Benutzer einen Client für Kontostand-Abrufe erzeugen und einen Client für das Trading. Und beide Zugänge separat aktivieren und wiederrufen.

Ein Client hat laut oauth2 jeweils eigene Zugangsdaten. Was hat der username und das password in der Schnittstelle der comdirect zu suchen? Und warum gibt es keinen vom Benutzer konfigurierbaren Scope je Client?

Immerhin liegen die Zugangsdaten ja auf einem Server und nicht auf dem Rechner vom Benutzer. Man gewährt niemals einem Server Vollzugriff in solch einem Fall.

Die REST Schnittstelle der comdirect ist aus meiner Sicht nicht professionell umgesetzt. oauth2 liefert seit Jahren eine gesteigerte Sicherheit im Netz, warum versucht die comdirect das wieder aufzuweichen?

[SMT_Erik]

Hallo @CommunityDev,

danke für deine Anfragen. Ich habe meine fachkundigen Kollegen um eine Antwort gebeten. Sobald ich etwas von ihnen höre, melde ich mich wieder bei dir.

Gruß

Erik

[SMT_Erik]

Hallo @CommunityDev,

kurz vorm Jahresultimo habe ich noch eine Antwort aus unserer Fachabteilung bekommen.

Vielen Dank für deine Hinweise. Insbesondere konfigurierbare Scopes und mehrere Credentials pro Nutzer wurden schon oft gewünscht und sind für zukünftige Entwicklungen geplant.

Für das aktuelle Authentifizierungsverfahren haben verschiedenste Überlegungen eine Rolle gespielt. Im Vordergrund stand immer, ein für versierte Entwickler einfach anzubindendes Banking API inkl. des umfassenden comdirect-Tradings anzubieten (was übrigens deutschlandweit ziemlich einzigartig ist!).

Das Verfahren hat mehrfach Sicherheits- und Revisionsaudits bestanden. Unter anderem spielen PSD2-Vorgaben eine Rolle, die im Web-Frontend anders gelöst sind, zum Beispiel durch die jederzeit mögliche TAN-Abfrage für PSD2-relevante Daten.

Die Nutzung unserer REST API steht jedem frei. Alternativ können die Funktionen auf unserer Webseite oder in den Apps genutzt werden.

Gruß & einen guten Rutsch ins neue Jahr!

Erik