Wow, damit machst Du ein ganz schönes Faß auf

Letztlich musst Du - kryptographisch abgesichert - einen Schlüsselaustausch vornehmen, so dass Endgerät und Server am Ende jeweils den public key des Partners haben - und auch sicher sein können, dass die andere Stelle tatsächlich der gewünschte Kommunikationspartner ist. Speichern kannst Du derartige Schlüssel dann z. B. in der Key Chain.

Für den initialen Schlüsselaustausch gibt es verschiedene Ansätze. Seitens der App zum Beispiel eine TLS-gesicherte Verbindung zum Server mit Überprüfung des Zertifikates inkl. Cert Pinning. Dann kannst Du schon einmal sicher sein, mit dem richtigen Backend zu sprechen. In der App wird dann ein Schlüsselpaar generiert und dessen public key an den Server geschickt.

Die Server-Seite muss nun der Benutzer-ID vertrauen. Falls sich der Benutzer mit seiner eMail-Adresse registriert, ist eine Bestätigungsmail mit einem Aktivierungslink Usus. Besser wäre ein standardisierter ID-Provider. Nun weiss der Server, dass der oben geschickte Key vom angeblichen Benutzer kam und speichert ihn ebenfalls als "vertrauenswürdig".

Mit diesen gegenseitig bekannten öffentlichen Schlüsseln kann nun eine Kommunikation asymmetrisch verschlüsselt werden oder - bei größeren Datenmengen - zu Beginn ein symmetrischer Schlüssel übermittelt werden, den man für die Masse nutzt (asymmetrische Verfahren wie RSA sind vergleichsweise langsam).

Soweit die Theorie und ein möglicher Ansatz über Cert Pinning und zweistufiges Onboarding. Es gibt aber diverse Lösungen und vor allem viele Möglichkeiten, in der Implementierung etwas falsch zu machen und damit eine Sicherheitslücke zu schaffen. Ich würde einmal in bestehende Verfahren schauen, z. B. Sign in with Apple...

Mattes

Hm,

warum willst du eine Verbindung die eh schon verschlüsselt ist (TLS) noch einmal verschlüsseln?

Ich glaube da schießt du über das Ziel hinaus.

TLS ist klare Voraussetzung und zwar ohne irgendwelche abgeschalteten Verifications des Zertifikats. Aber wenn die Verbindung steht, dann ist eine weitere Verschlüsselung nicht mehr nötig.

Wenn jemand einen neuen Account anlegt, dann gibt er Username und gewünschtes Passwort an. Das wird dann gehashed auf dem server gespeichert. Das ist eigentlich alles was benötigt wird um sicherzustellen das sich derjenige einloggt der den account erstellt hat.
Mit einer zusätzlichen email mit aktivierungslink kannst du nur verhindern, dass ein Bot tausende von account anlegt z.B. Benötigt für die Sicherheit wird es aber nicht.

Nun kann natürlich der dumme User seine Credentials weitergeben (oder sein Rechner wird gehackt und jemand anders bekommt die Credentials)

Hier kommt dann MFA ins Spiel, das heute ja der letzte Schrei ist.
MFA ist aber nichts anderes, als das zusätzlich zum Password noch ein weitere ID benötigt wird. Diese wird auf dem server erzeugt und kann über eine SMS, eine email oder sonst was verschickt werden und muss dann vom User angegeben werden beim login.
Das verhindert, das ein user sich anmelden wenn er einfach nur username und password kennt, macht das anmelde aber auch total umständlich, so das man meiner Meinung nach gut überlegen sollte ob sich der Aufwand/Nutzen lohnt.
Würde dieses Forum z.B. auf die Idee kommen MFA einzuführen, dann würde ich mich wohl nicht mehr jeden Tag anmelden.

Hast recht, für eine rein vom Client initiierte Kommunikation gingen die Pferde etwas mit mir durch. Allerdings würde ich auch in diesem Fall - je nach Anforderung - Certificate Pinning erwägen: Letztlich kann auch die Authentizität des Servers wichtig sein, nur allzu leicht könnte ein "Man in the Middle" die TLS-Verschlüsselung terminieren und den Inhalt lesen ... trotz aller Überprüfungen der Zertifikatskette auf Gültigkeit und Revocations. Das passiert im täglichen Leben häufiger als man denkt und Apple macht Identity Pinning mittlerweile vergleichsweise leicht.

Sollte der Server dann auch Datenübertragungen initiieren, müsste er ebenfalls das korrekte (Client-) Zertifikat kennen ... dann rutschst Du langsam in den von mir oben beschriebenen Fall. Aber das war hier sicher mit Kanonen auf Spatzen geschossen.

Gut implementiertes MFA möchte ich nicht missen - für ein Diskussionsforum Overkill, aber wenn ich auf vertrauliche Daten zugreife oder sensible Transaktionen vornehme, schätze ich den zusätzlichen Schutz.

Beim zweiten Lesen von @bastls Post scheint es ihm allerdings eher um API-Access-Tokens zu gehen, welche die App benötigt, um Cloud-Dienste zu konsumieren. Zumindest lässt der verlinkte c't-Artikel dies vermuten. Hier fällt mir nichts besseres ein, als diesen Token dynamisch von einem Backend zu holen oder mit einer proprietären Verschlüsselung (ausserhalb der App) zu verschlüsseln und "on the fly" zu entschlüsseln...

Mattes

Ich habe kein Ahnung wie denn bei einer End-To-End-Verschlüsselung ein Man in the middle irgendetwas ausrichten soll.

Beim zweiten Lesen von @bastls Post scheint es ihm allerdings eher um API-Access-Tokens zu gehen, welche die App benötigt, um Cloud-Dienste zu konsumieren. Zumindest lässt der verlinkte c't-Artikel dies vermuten. Hier fällt mir nichts besseres ein, als diesen Token dynamisch von einem Backend zu holen oder mit einer proprietären Verschlüsselung (ausserhalb der App) zu verschlüsseln und "on the fly" zu entschlüsseln...

API requests haben I’m client einfach nichts zu suchen. Dafür gibt es ja schließlich ein backend.

Weil es dann eben keine durchgängige End-To-End-Verschlüsselung ist. Browse mal in einem Unternehmen, das z. B. Cloud-Proxies mit TLS-Inspection nutzt, eine Website per HTTPS an: Dein Browser wird eine TLS-gesicherte Verbindung zum Cloud-Proxy aufbauen, der wiederum (hoffentlich auch per TLS) mit dem Zielserver spricht.

Ohne manueller Überprüfung des Zertifikats im Browser oder eben Certificate Pinning wirst Du das nicht mitbekommen. Dies ist z. B. bei SASE-Anbietern gängige Praxis - wie sonst sollten sie auch TLS-Verkehr untersuchen?
Unsinn. Wie bindest Du denn z. B. Dropbox in einer App ein? Es gibt bestimmt auch andere Beispiele, aber zumindest dort arbeitet die App mit einem Access-Token, der durchaus auf dem Client gespeichert werden kann. Und natürlich macht der Client die API-Calls, kein Backend - ja, es gibt auch "stand alone" Apps.

Mattes