Authentifizierung an API bei aktivierter 2FA

fkmm-webmaster

@davidschilling der Login ist nicht automatisiert. Wir prüfen lediglich über die CT-API ob die Login-Daten eines Benutzers korrekt sind. Nun kann ich den Benutzer zwar nach dem 2FA Code fragen, aber diesen nicht über die API verifizieren (zumindest nicht über die Legacy-API).

Der Token-Login bringt mir in diesem Fall nichts.

Wäre es nicht möglich eine Beta-Version der API Dokumentation online zu stellen?

fkmm-webmaster

@davidschilling sagte in Authentifizierung an API bei aktivierter 2FA:

https://testdavid.church.tools/api/whoami?login_token=$LOGIN_TOKEN&user_id=$USER_ID

Wieder eine neue API für die ich keine Dokumentation habe ...

davidschilling

Wie oben schon jemand erwähnt hat ist diese Api aktuell in Entwicklung.

Wir werden dafür eine Dokumentation herausbringen. Aber die ist noch nicht fertig.
Wir wollen auch keine Dokumentation für eine Api herausbringen die sich noch ändern kann, weil sich sonst zu viele schon auf diese Api verlassen.

fodinabor

@fkmm-webmaster für den aktuellen Fall einfach die URLs verwenden, die schon genannt wurden.. was super zum testen der Parameter funktioniert ist Postman.
Sonst einfach nachfragen... finde die meisten Sachen mittlerweile recht schnell..

@davidschilling ich muss tatsächlich sagen, dass ich auch für eine Beta Dokumentation wäre... einfach irgendwo sichtbar anzeigen, dass sich das ändern kann und wird.. dadurch, dass funktionen, wie das Anmelden mit 2FA nicht mehr über die alte API durchführbar sind, macht es in meinen Augen notwendig über die Möglichkeit der neuen API zu informieren.

fkmm-webmaster

Wie ich oben geschrieben habe, ist das übliche Vorgehen, die API als Beta oder unstable zu veröffentlichen. So macht es z.B. GitHub.

Das Nutzer die CT selber hosten sich die notwendige Infos aus dem source code ziehen können führt zu einer Zweiklassengesellschaft.

Wie oben auch angemerkt denke ich daß die Rückmeldung von Usern bezüglich der API während der Entwicklung wichtig ist. Sonst hat man zwar eine Schnittstelle die aber vielleicht nicht das wiederspiegelt was man als Nutzer benötigt.

fkmm-webmaster

@fodinabor sagte in Authentifizierung an API bei aktivierter 2FA:

Sonst einfach nachfragen... finde die meisten Sachen mittlerweile recht schnell..

Danke für das Angebot

fodinabor

@davidschilling sagte in Authentifizierung an API bei aktivierter 2FA:

https://testdavid.church.tools/api/whoami?login_token=$LOGIN_TOKEN&user_id=$USER_ID

Authentifizierung im GET Parameter? Echt jetzt?

Marcel

@fodinabor

HTTPS
Token

fodinabor

@Marcel

https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
ja, ich weiß, das wird selten im Browser direkt verwendet werden, es fördert aber unsichere Nutzung der API, Webserver Logs bleiben und einige Nutzer werden möglicherweise die API aus einem Firmennetz / Rechenzentrum raus aufrufen, wo es üblich ist Traffic zu analysieren und HTTP(S) Requests zu loggen... Instagram hatte da letztens Spaß:

Das Token ersetzt das Passwort perfekt... User ID + Token == Username + Passwort
Du kannst dich vll. nicht direkt in der CT Oberfläche anmelden, hast über die API aber exakt die gleichen Rechte.

Marcel

@fodinabor doch damit kannst dich auch direkt in CT anmelden, musst dir nur die Cookies kopieren.

Wenn man CT normal nutzt, läuft die Auth über die Cookies und nicht über Query Params.

Wenn man die API entsprechend nutzt, kann es eine durchaus legitime Möglichkeit sein, den Token via Query Param zu verschicken. In der Annahme, dass CT hier richtig loggt

Mal anders rum, die von dir genannten Dinge sind Angriffe auf die TLS Verbindung. Wenn man da reinschauen kann, dann kann man auch noch den Request Body anschauen.

fodinabor

@Marcel hab grad nicht dran gedacht, ist ja noch besser

klar, wenn CT richtig loggt.. sonst gibts immer noch paar Gemeinden, die hosten (lassen), wo vermutlich die vollen GET Strings geloggt werden (was ja nicht wirklich verwerflich ist) -> Tokens im Webserver Log.

Ähm.. klar kann man. Normal wird aber nur der GET String geloggt.

Heißt: GET Parameter tauchen sehr viel häufiger in Logs und diese Logs werden nicht unbedingt mit besonderer Sorgfalt geschützt. Ja.. die Credentials im GET Param zu haben ist sehr convenient, da man sich um sehr viel weniger kümmern muss.. aber:

die meisten HTTP client APIs sind mittlerweile ausgereift und einfach genug mit POST zu verwenden
HTTP Header setzen ist ähnlich schnell gemacht, da könnte man dann mit Bearer Token arbeiten (oder gleich auf OAuth2 setzen), dann gehen auch weiterhin GET Requests nur halt, dass die Authentifizierungs informationen nicht in der URL enthalten sind.

Alles was ich sagen will, ist dass ich es für eine neu entworfene RESTful API eher schade finde, dass solche eher schlüpfrigen Entscheidungen getroffen werden...