Announcement: there is an English version of this forum on Hallo, beim Anschauen einiger APIs für Dienste im Internet (Auktionsplattformen, Geldanlage, Girokonto, Versionsverwaltung, ...) gibt es zwar eine Dokumentation für viele API-Funktionen, aber es fehlt immer die Konto-Verwaltung. Man kann zwar Profileinträge programmatisch ändern, aber z. B. nicht das Passwort. Den Nutzernamen ändern, einen neuen Account anlegen, 2FA einrichten, alles das geht nicht über die offizielle API. Warum lassen die gerade das weg? Ich fände es viel sicherer, wenn mein Passwortmanager sich würde z. B. einmal im Monat bei allen Diensten einloggen und dort das Passwort ändern. Der normale Login würde auch direkt vom Passwortmanager durchgeführt werden. So würde nie irgendwo ein Passwort angezeigt oder eingegeben werden. Es könnte so auch nicht abgefisht werden.
2FA per API anlegen widerspricht dem Sinn von 2FA, weil dann ja garantiert der Zweite Faktor im selben Passwortmanager wie der erste liegt. Namen Ändern bei einer Bank ist eine Sache wo nach diversen Geldwäsche-Gesetzen usw. wohl vorher der Name auf deinem Perso geändert werden sollte. Erzwungenes Passwort-Ändern ist unsicher, und nach den aktuellen BSI-Regeln ist das Erzwingen von regelmäßigen Passwort-Änderungen eine schwere Sicherheitslücke, die unbehoben dem entsprechenden Anbieter wohl seine Zertifizierungen kostet, wenn er denn welche hatte.
Stefan H. schrieb: > Es könnte so auch nicht abgefisht werden. Du bist etwas sehr naiv. Ein Angreifer braucht dein Passwort nicht, es reicht der Session-Cookie. Da schützt dich dann auch keine MFA. Stefan H. schrieb: > Den Nutzernamen ändern, einen > neuen Account anlegen, 2FA einrichten, alles das geht nicht über die > offizielle API. Lies dir mal diesen Artikel durch. Da wird erklärt warum z.B. passwd nicht dazugedacht ist, aus einem script aufgerufen zu werden. https://mywiki.wooledge.org/BashFAQ/078
1 | Nothing you can do in bash can possibly work. The traditional passwd(1) does |
2 | not read from standard input. This is intentional. It is for your protection. |
3 | Passwords were never intended to be put into programs, or generated by |
4 | programs. They were intended to be entered only by the fingers of an actual |
5 | human being, with a functional brain, and never, ever written down anywhere. |
6 | So before you continue, consider the possibility that the authors of passwd(1) |
7 | were on to something, and you probably shouldn't be trying to script passwd(1) |
8 | input. |
9 | |
10 | Nonetheless, we get hordes of users asking how they can circumvent 35 years |
11 | of Unix security. And we get people contributing their favorite security- |
12 | removing "solutions" to this page. If you still think this is what you want, |
13 | read on. |
Stefan H. schrieb: > Ich fände es viel sicherer, wenn mein Passwortmanager sich würde z. B. > einmal im Monat bei allen Diensten einloggen und dort das Passwort > ändern. Das widerspricht seit diesem Jahr der NIST Empfehlung. https://pages.nist.gov/800-63-FAQ/#q-b05 > Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily > (e.g., periodically).
:
Bearbeitet durch User
Stefan H. schrieb: > Ich fände es viel sicherer, wenn mein Passwortmanager sich würde z. B. > einmal im Monat bei allen Diensten einloggen und dort das Passwort > ändern. Der normale Login würde auch direkt vom Passwortmanager > durchgeführt werden. So würde nie irgendwo ein Passwort angezeigt oder > eingegeben werden. Es könnte so auch nicht abgefisht werden. Eine sich periodisch wiederholende Abfrage ist der Garant dafür das man Dinge abfischen kann. Was denkst du wie dein "Passwortmanager" arbeitet? Er übermittelt das Passwort... Solch eine Thematik hat selbst Enigma einst den Hals gebrochen.
Εrnst B. schrieb: > nach den aktuellen > BSI-Regeln ist das Erzwingen von regelmäßigen Passwort-Änderungen eine > schwere Sicherheitslücke, die unbehoben dem entsprechenden Anbieter wohl > seine Zertifizierungen kostet, wenn er denn welche hatte. Man möge die entsprechende BSI Quelle angeben...
Ich A. schrieb: > Man möge die entsprechende BSI Quelle angeben... Entspricht fast 1:1 der oben angegebenen NIST Empfehlung. Seite 5: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/02_ORP_Organisation_und_Personal/ORP_4_Identitaets_und_Berechtigungsmanagement_Editon_2023.pdf?__blob=publicationFile&v=3
Εrnst B. schrieb: > Ich A. schrieb: >> Man möge die entsprechende BSI Quelle angeben... > > Entspricht fast 1:1 der oben angegebenen NIST Empfehlung. > > Seite 5: > > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/02_ORP_Organisation_und_Personal/ORP_4_Identitaets_und_Berechtigungsmanagement_Editon_2023.pdf?__blob=publicationFile&v=3 Du meinst also wie ich es dachte ORP.4.A23? Ich kann da aber keine "schwere Sicherheitslücke" von ableiten. Der Text spricht eindeutig von SOLLTE und nicht MUSS oder wenigstens MÜSSTE... Im weiteren Verlauf wird sogar eindeutig die Möglichkeit einer rein Zeitgesteuerten erzwungenen Änderung eröffnet.
Falls du bei der Platform selbst per OpenID oder Oauth oder WebID oder DID dein eigener Identity Provider sein kannst, kannst du für solche Sachen APIs selbst machen. PS: Ja, mittlerweile gibt es viel zu viele Standards. Sie haben nicht alle den gleichen Anwendungsbereich, aber sie sind alle überverkompliziert.
:
Bearbeitet durch User
Ich A. schrieb: > Ich kann da aber keine "schwere Sicherheitslücke" von ableiten. > Der Text spricht eindeutig von SOLLTE und nicht MUSS oder wenigstens > MÜSSTE... Hast du mal so ein IT-Sicherheits-Audit mitgemacht? Wenn du irgendwie von den "SOLL"-Bestimmungen abweichst, kriegt der Auditor ganz feuchte Augen, weil er sein Honorar gerade um mehrere k€ wachsen sieht. Und dann fordert er erstmal ein paar Akten-Meter an, wie du zu der Entscheidung gekommen bist, wer sie Abgesegnet hat, welche Alternativen evaluiert wurden, wie die Entscheidung dokumentiert wurde, wer die Dokumentation kontrolliert und freigegeben hat usw. Ansonsten sind die "SOLL" Bedingungen in dem Dokument schon recht zwingend... z.B. "SOLLST" du ein sicheres Verfahren zum Passwort-Reset nutzen. "MUSST" aber nicht. Wäre eine Login-Maske die per "Reset"-Knopf jedes beliebige Passwort auf "123456" ändert OK?
Wozu benoetigt man eine API fuer die angefragten Operationen ? Um schnell und bequem Tausende von Konten zu erzeugen, zu uebernehmen, oder umzukonfigurieren.
:
Bearbeitet durch User
Ich A. schrieb: > Ich kann da aber keine "schwere Sicherheitslücke" von ableiten. > Der Text spricht eindeutig von SOLLTE und nicht MUSS oder wenigstens > MÜSSTE... Es ist zwar kein Gesetzestext, aber ein Text mit juristischen Implikationen. Den sollte ;-) man dementsprechend interpretieren. https://de.wikipedia.org/wiki/Muss-,_Soll-_und_Kann-Vorschrift
Εrnst B. schrieb: > Ich A. schrieb: >> Ich kann da aber keine "schwere Sicherheitslücke" von ableiten. >> Der Text spricht eindeutig von SOLLTE und nicht MUSS oder wenigstens >> MÜSSTE... > > Hast du mal so ein IT-Sicherheits-Audit mitgemacht? > Ja aktiv, aktuell gerade wieder. Εrnst B. schrieb: > Wenn du irgendwie von den "SOLL"-Bestimmungen abweichst, kriegt der > Auditor ganz feuchte Augen, weil er sein Honorar gerade um mehrere k€ > wachsen sieht. Und dann fordert er erstmal ein paar Akten-Meter an, wie > du zu der Entscheidung gekommen bist, wer sie Abgesegnet hat, welche > Alternativen evaluiert wurden, wie die Entscheidung dokumentiert wurde, > wer die Dokumentation kontrolliert und freigegeben hat usw. Die entsprechende Doku hat man natürlich beim Audit bereits vorliegen, weil man den entsprechenden Prozess natürlich evaluiert und ausgearbeitet hat. Ich kann da aber noch immer keine "schwere Sicherheitslücke" von ableiten. Und die wäre zusätzlich zum BSI GS im KRITIS Umfeld dann schon doof. Der BSI GS dreht sich ganz oft um Prozesse und Organisation. Wenn man die halt nicht hat: Dumm gelaufen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.