Table of Contents
Einleitung
Der Aufbau sicherer Authentifizierungssysteme für iOS-Anwendungen ist eine grundlegende Verantwortung für Entwickler. Mit dem Anstieg anspruchsvoller Cyber-Bedrohungen kann eine einzige Schwachstelle im Anmeldefluss sensible Benutzerdaten offenlegen, den Ruf der Marke schädigen und zu behördlichen Sanktionen führen. Apples Ökosystem bietet leistungsstarke Sicherheits-Frameworks, aber ihre richtige Nutzung erfordert ein tiefes Verständnis der Best Practices. Dieser Artikel beschreibt wesentliche Strategien - von robustem Credential-Management bis hin zu kryptographischen Protokollen - damit Sie eine Authentifizierungsarchitektur entwerfen können, die gängigen Angriffen standhält und gleichzeitig eine nahtlose Benutzererfahrung bietet.
Implementieren Sie starke Authentifizierungsmethoden
Sich ausschließlich auf die passwortbasierte Authentifizierung zu verlassen, reicht nicht mehr aus. Angreifer verwenden häufig Credential-Stuffing-, Phishing- oder Brute-Force-Techniken, um Konten zu kompromittieren. Um diese Risiken zu minimieren, sollten Sie Multi-Faktor-Authentifizierung (MFA) und moderne Identitätsprotokolle anwenden.
Multi-Factor Authentication (MFA)
MFA kombiniert zwei oder mehr unabhängige Faktoren: etwas, das der Benutzer kennt (Passwort), etwas, das er hat (ein vertrauenswürdiges Gerät oder Hardware-Token) und etwas, das er ist (biometrisch). Für iOS-Apps kann die Integration von MFA durch zeitbasierte Einmalpasswörter (TOTP) erreicht werden, die von Authentifizierungs-Apps, Push-basierten Genehmigungsanforderungen oder SMS-Codes generiert werden (obwohl SMS aufgrund von SIM-Swapping-Angriffen zunehmend entmutigt wird). Apples Framework AuthenticationServices unterstützt den ASAuthorizationController für die Verwaltung von MFA-Flows, aber Sie müssen Token-Lebensdauern und risikobasierte Step-up-Authentifizierung sorgfältig behandeln.
OAuth 2.0 und OpenID Connect
Anstatt ein benutzerdefiniertes Authentifizierungs-Backend zu erstellen, nutzen Sie Industriestandards wie OAuth 2.0 und OpenID Connect. Diese Protokolle ermöglichen es Ihrer App, die Authentifizierung an vertrauenswürdige Anbieter (Apple, Google oder Ihren eigenen Autorisierungsserver) zu delegieren, während Sie die feine Kontrolle über Umfange und Berechtigungen behalten. Wenn Sie OAuthenticationSession oder den neueren ASAuthorizationController verwenden, um sichere, systemverwaltete Browsersitzungen zu präsentieren. Dies verhindert das Abfangen von Anmeldeinformationen durch bösartige Apps und stellt sicher, dass Benutzer die legitime Anmeldeseite des Anbieters sehen. Erzwingen Sie immer die Proof Key for Code Exchange (PKCE) Erweiterung (RFC 7636) für öffentliche Clients wie mobile Apps - es mindert Autorisierungscode-Abfangen Angriffe, auch wenn die Umleitungs-URI kompromittiert ist.
Erfahren Sie mehr über PKCE und seine Bedeutung für mobile Apps.
Sichere Aufbewahrung von Credentials
Alle auf dem Gerät gespeicherten Anmeldeinformationen, Token oder kryptografischen Schlüssel müssen vor unbefugtem Zugriff geschützt sein - auch wenn das Gerät durch Malware oder physischen Diebstahl kompromittiert wird. iOS bietet mehrere Mechanismen für diesen Zweck.
Keychain-Dienste
Der iOS Keychain ist der sicherste Ort, um kleine Teile sensibler Daten wie Passwörter, Authentifizierungstoken und kryptografische Schlüssel zu speichern. Im Gegensatz zu den Standard- oder einfachen Dateien des Benutzers werden Keychain-Einträge mit einem Hardware-gestützten Schlüssel verschlüsselt, der an die Secure Enclave des Geräts gebunden ist. Wenn Sie ein Token speichern, verwenden Sie das entsprechende kSecClassGenericPassword für undurchsichtige Geheimnisse. Legen Sie das kSecAttrAccessible]-Attribut zu kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly fest, um sicherzustellen, dass die Daten nur entschlüsselt werden können, wenn das Gerät entsperrt ist und ein Passcode festgelegt ist und er nicht gesichert oder zu einem anderen Gerät migriert werden kann. Speichern Sie niemals Anmeldeinformationen in , Core Data
Apples Keychain Services Dokumentation
App Sandbox und Datenschutz
Über den Keychain hinaus erzwingen Sie die Datenschutz-APIs von iOS auf Dateiebene. Legen Sie beim Erstellen von Dateien in den Dokumenten- oder Caches-Verzeichnissen die Dateischutzklasse auf NSFileProtectionCompleteUnlessOpen oder, für mehr Sicherheit, NSFileProtectionComplete (verfügbar nur, wenn das Gerät entsperrt ist). Dies verwendet die gleiche Hardware-Verschlüsselungsmaschine wie der Keychain und stellt sicher, dass sogar die Dateisystemschicht verschlüsselt ist. Darüber hinaus konfigurieren Sie die App Info.plist, um “Dateischutz bis zur ersten Benutzerauthentifizierung” zu aktivieren, um die Verschlüsselung auf Netzwerkverbindungen und Festplatten-Caches zu erweitern.
Verwalten von kryptographischen Schlüsseln
Wenn Ihr Authentifizierungssystem digitale Signaturen, ephemere Schlüssel oder symmetrische Verschlüsselung verwendet, erzeugen und speichern Sie diese Schlüssel nach Möglichkeit mit der Secure Enclave. Die SecKey API ermöglicht es Ihnen, elliptische Kurvenschlüssel (z. B. P-256) zu erstellen, die die Secure Enclave niemals verlassen. Dadurch sind sie auch bei einem Kompromiss auf Kernelebene gegen Extraktion resistent. Für Schlüssel, die im Speicher verwendet werden müssen, setzen Sie sie nach der Verwendung immer auf Null und vermeiden Sie die Serialisierung an unsicheren Orten.
Biometrische Authentifizierung verwenden
Touch ID und Face ID bieten eine Kombination aus starker Sicherheit und exzellenter Benutzererfahrung. Durch das Entladen der Passworteingabe für eine biometrische Verifizierung reduzieren Sie die Angriffsfläche von Phishing und Keylogging und senken gleichzeitig die Reibung für wiederkehrende Benutzer.
Integration von LocalAuthentication
Apples LocalAuthentication Framework bietet eine Standardschnittstelle zur Auswertung biometrischer Richtlinien. Verwenden Sie LAContextevaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics Policy. Geben Sie immer eine lokalisierte Grundzeichenfolge an, die klar beschreibt, warum die App eine Authentifizierung benötigt (z. B. “Anmelden an Ihrem Konto”). Für moderne Geräte bevorzugen Sie Face IDs robuste Tiefenabbildung – es ist deutlich schwieriger zu fälschen als Touch ID. Entwerfen Sie Ihren Fallback jedoch anmutig: Wenn Biometrie nicht registriert ist oder fehlschlägt (z. B. ein Benutzer trägt eine Gesichtsmaske), fordern Sie den Passcode der App oder den Gerätepasscode mit LAPolicyDeviceOwnerAuthentication).
Best Practices für biometrisch geschützte Token
Speichern Sie not die biometrische Vorlage selbst – sie wird von der Secure Enclave behandelt und nie der App ausgesetzt. Speichern Sie stattdessen ein Zugriffstoken innerhalb des Keychains mit einer biometrischen Zugriffssteuerungsliste (ACL). Fügen Sie ein SecAccessControl-Objekt mit kSecAccessControlBiometryCurrentSet oder kSecAccessControlUserPresence an. Diese Konfiguration stellt sicher, dass das Token nur nach einem erfolgreichen biometrischen Scan abgerufen werden kann. Beachten Sie, dass bei einer Registrierung eines neuen Fingers oder Änderungen der Face ID-Daten die vorhandenen biometrischen ACL-Elemente unzugänglich werden (es sei denn, Sie verwenden kSecAccessControlBiometryAny, was weniger sicher ist). Planen Sie dies, indem Sie eine Fallback-
Apple LocalAuthentication documentation
Implementieren Sie ein richtiges Sitzungsmanagement
Sobald sich ein Benutzer authentifiziert hat, ist die sichere Aufrechterhaltung dieser Sitzung von entscheidender Bedeutung.Unzureichende Sitzungsbehandlung kann zu Token-Diebstahl, Sitzungsfixierung oder Wiederholungsangriffen führen.
Token-basierte Sitzungen
Bevorzugt oAuth 2.0 Bearer-Token-Paare: ein Access-Token (kurzlebig, typischerweise 15-60 Minuten) und ein Refresh-Token (längerlebig, z.B. 30 Tage). Speichern Sie beide im Keychain mit entsprechender Zugriffskontrolle. Legen Sie niemals Zugriffstoken in URL-Abfragezeichenfolgen frei; übertragen Sie sie nur über den Authorization-Header mit dem Bearer-Schema. Wenn das Access-Token abläuft, kann die App das Refresh-Token stillschweigend verwenden, um ein neues zu erhalten, ohne den Benutzer zu unterbrechen. Implementieren Sie jedoch die Refresh-Token-Rotation (jede Refresh-Anfrage gibt ein neues Refresh-Token zurück und ungültig macht den alten), um die Auswirkungen eines gestohlenen langlebigen Tokens zu begrenzen.
Widerruf und Logout
Stellen Sie einen klaren Abmeldemechanismus bereit, der Token sowohl lokal als auch serverseitig ungültig macht. Auf dem Gerät löschen Sie die Token sofort aus dem Keychain. Auf dem Server führen Sie eine Allowlist (oder eine Token-Widerrufsliste), so dass Backend-Dienste jedes widerrufene Token ablehnen. Verwenden Sie für maximale Sicherheit token-Bindung (z. B. JWTs “cnf” -Behauptung mit einem öffentlichen Schlüssel), um das Token an ein bestimmtes Gerät oder Schlüsselpaar zu binden - dies verhindert, dass ein gestohlenes Token an anderer Stelle verwendet wird.
Session Timeout und Inaktivität
Implementieren Sie im Leerlauf-Sitzungs-Timeouts, die Benutzer nach einer Zeit der Inaktivität automatisch abmelden (z. B. 15 Minuten bei Finanz-Apps), betrachten Sie eine weiche Zeit, die die App lokal sperrt, aber die Sitzung beibehält, bis der Benutzer erneut eine kurze PIN oder einen biometrischen Scan eingibt. Dies gleicht Sicherheit und Benutzerfreundlichkeit aus. Ermitteln Sie auch Sitzungsanomalien mithilfe von Geräte-Fingerabdrücken (IP-Adresse, User-Agent) und erzwingen Sie eine erneute Authentifizierung, wenn der Risiko-Score steigt.
Sichere Aufbewahrung von Token
Wir haben bereits den Keychain-Speicher abgedeckt, aber beachten Sie, dass Aktualisierungstoken niemals an nicht vertrauenswürdige Umgebungen gesendet werden sollten. Wenn Ihre App eine Webansicht zur Authentifizierung verwendet, stellen Sie sicher, dass JavaScript nicht über document.cookie auf die Token zugreifen kann (setzen Sie die Flags HttpOnly und SameSite=Strict auf Cookies, die vom Server verwendet werden). Für native Token verwenden Sie immer den Keychain mit dem Attribut kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, das die Extraktion verhindert, wenn das Gerät nach einem Neustart entsperrt wird.
Sicherstellen einer sicheren Kommunikation
Der gesamte Netzwerkverkehr zwischen der iOS-App und Ihren Servern muss mit TLS 1.2 oder höher verschlüsselt werden. Auch wenn Authentifizierungsdaten niemals übertragen werden, stellt unverschlüsselter Datenverkehr Metadaten (API-Endpunkte, Anforderungsmuster) frei, die Angreifern helfen können.
App Transport Security (ATS)
Apple setzt ATS standardmäßig in iOS 9 und höher durch, was HTTPS-Verbindungen erfordert, die modernen Sicherheitsstandards entsprechen. Sie sollten niemals Ausnahmen zu NSAppTransportSecurity hinzufügen (es sei denn, dies ist für ältere Dienste von Drittanbietern absolut erforderlich und nur nach sorgfältiger Analyse). Setzen Sie NSAllowsArbitraryLoads auf NO Für Ihre eigenen API-Endpunkte verwenden Sie TLS 1.3 mit Vorwärtsgeheimnis. Stellen Sie sicher, dass Ihr Server eine starke Chiffriersuite unterstützt (z. B. TLS AES 128 GCM SHA256) und deaktivieren Sie schwache Chiffriersuiten.
Anheften von Zertifikaten
Selbst mit HTTPS könnte eine kompromittierte Zertifikatsstelle (CA) ein betrügerisches Zertifikat für Ihre Domain ausgeben. Implementieren Sie das Anheften von Zertifikaten, indem Sie den öffentlichen Schlüssel des Servers (oder den Zertifikats-Hash) in Ihre Anwendungsbinärdatei einbetten. Verwenden Sie die NSURLSessionDelegationsmethode URLSession:didReceiveChallenge:completionHandler:, um den angehefteten Schlüssel gegen das präsentierte Zertifikat des Servers zu validieren. Anheften Sie nicht an das Blattzertifikat selbst (es muss jährlich aktualisiert werden), sondern an den öffentlichen Schlüssel der zwischengeschalteten CA. Ein alternativer Ansatz ist die Verwendung der TrustKit Bibliothek, aber achten Sie auf App-Updates, wenn sich der Anheftschlüssel ändert.
Token-Übertragung
Senden Sie immer Token über die HTTPS-Verbindung. Fügen Sie niemals Token in den Pfad oder die Abfragezeichenfolge ein (sie können von zwischengeschalteten Proxies protokolliert oder zwischengespeichert werden). Verwenden Sie den Authorization: Bearer <token> Header. Für zusätzliche Sicherheit binden Sie Token an die TLS-Sitzung, indem Sie einen Hash des Master-Secrets (die “tls-unique”-Kanalbindung) in die Token-Anfrage aufnehmen - dies verhindert Wiederholungsangriffe über verschiedene Verbindungen hinweg.
OWASP Mobile Top 10 – Sichere Kommunikation
Regelmäßige Sicherheitsupdates und Tests
Sicherheit ist keine einmalige Aufgabe. Da neue Sicherheitslücken in iOS, Bibliotheken von Drittanbietern und Ihrem eigenen Code auftreten, ist es unerlässlich, wachsam zu bleiben.
Abhängigkeitsmanagement
Prüfen Sie jede Bibliothek von Drittanbietern, die Sie in Ihren Authentifizierungsfluss integrieren. Verwenden Sie Tools wie CocoaPods-Audit oder die eingebaute Validierung von SPM, um bekannte Schwachstellen zu erkennen. Bevorzugen Sie gut gepflegte Bibliotheken mit einer Sicherheitsbilanz, wie Alamofire (nur wenn nötig; rohe URLSession ist oft sicherer) oder Jose für JSON Web Token. Vermeiden Sie Abhängigkeiten, die nativen Code oder das Netzwerk direkt ohne ordnungsgemäße Sicherheitsüberprüfung ausführen.
Automatisiertes Security Testing
Integrieren Sie Sicherheitsscans in Ihre CI/CD-Pipeline. Verwenden Sie statische Analysetools (z. B. SonarQube mit Swift-Regeln oder SwiftLint mit sicherheitsgerichteten Regeln), um fest codierte Geheimnisse, unzureichende Entropie oder unsachgemäße Kryptonutzung zu kennzeichnen. Für dynamische Analysen nutzen Sie Xcodes Address Sanitizer und GuardMalloc, um Speicherkorruption zu erfassen. Periodische manuelle Penetrationstests sind ebenfalls entscheidend: Testen auf Injektionsangriffe, unsichere Datenspeicherung und Sitzungsmanagementfehler (z. B. Token-Wiederverwendung).
Reaktion auf Vulnerabilitäts-Offenlegungen
Einen Prozess für die Handhabung von Fehlerberichten haben. Apple stellt das Security Feedback Tool zur Verfügung. Erwägen Sie die Teilnahme am Apple Security Bounty Programm. Halten Sie den Authentifizierungscode Ihrer App immer konform mit dem neuesten iOS SDK – Apple veraltet oft unsichere APIs (z. B. UIWebView wurde entfernt; verwenden Sie stattdessen ASWebAuthenticationSession).
Zusätzliche Sicherheitsüberlegungen
Ein umfassendes Authentifizierungssystem geht über den zentralen Login-Fluss hinaus und adressiert diese komplementären Bereiche, um verbleibende Angriffsvektoren zu schließen.
Account Recovery und Passwort-Reset
Schwache Mechanismen zur Zurücksetzung von Kennwörtern lösen die Sicherheit einer starken Authentifizierung zunichte. Verwendung zeitlich begrenzter Einmal-Token, die an verifizierte E-Mail-Adressen oder Telefonnummern gesendet werden. Vermeiden Sie es, während des Wiederherstellungsprozesses offenzulegen, ob ein Konto existiert, um Aufzählungsangriffe zu verhindern. Erzwingen Sie die gleichen Kennwortstärkeregeln wie die ursprüngliche Registrierung.
Rate Limiting und Brute-Force-Schutz
Serverseitige Ratenbegrenzung für Anmelde-Endpunkte implementieren (z. B. 5 Versuche pro Minute pro IP oder Benutzer). Nach mehreren fehlgeschlagenen Versuchen CAPTCHA oder eine verzögerte Wiederholung erfordern. Unter iOS können Sie auch das accelerate Framework verwenden, um eine Proof-of-Work-Herausforderung zu berechnen (obwohl dies weniger häufig ist).
Datenschutz und Datenminimierung
Erfassen Sie nur die für die Authentifizierung notwendigen Daten. Vermeiden Sie Berechtigungen, die keine direkte Beziehung haben (z. B. Kontakte, Standort), es sei denn, der Benutzer entscheidet sich ausdrücklich dafür. Befolgen Sie die Datenschutzrichtlinien von AppleSign in with AppleSign in with AppleSign in with AppleSign in with AppleSign in with AppleSign in with AppleSign in your Privacy: Wenn Sie diese Funktion integrieren, verwenden Sie die private Relay-E-Mail-Adresse des Benutzers, um das Tracking zu verhindern.
Produktbescheinigung
Für Hochsicherheits-Apps (z. B. Banking) sollten Sie DeviceCheck oder App Attest (über den DCAppAttestService) verwenden, um zu bestätigen, dass die Anforderung von einer authentischen Kopie Ihrer App stammt, die auf einem legitimen Gerät ausgeführt wird. Dies verhindert, dass Anfragen von verwurzelten oder jailbroken-Geräten emuliert werden. Kombinieren Sie die Bescheinigung mit dem Authentifizierungstoken, um eine hardwaregestützte Sicherheitsanweisung zu erstellen.
Schlussfolgerung
Die Authentifizierung unter iOS zu sichern ist ein vielschichtiges Unterfangen, das Kryptographie, Protokolldesign, Speicherung und laufende Wartung umfasst. Durch die Implementierung von MFA mit PKCE, das Speichern von Geheimnissen im Keychain mit biometrischen Zugriffskontrollen, das Verwalten von Tokenlebenszeiten mit Rotation, das Erzwingen verschlüsselter Kommunikation mit Pinging und kontinuierliches Testen können Sie das Risiko von Kompromissen drastisch reduzieren. Das Ökosystem, das Apple bietet - von der Secure Enclave bis hin zu LocalAuthentication und App Attest - bietet starke Primitive, aber sie müssen korrekt angewendet und auf dem neuesten Stand gehalten werden. Investieren Sie die Zeit, um Ihren Authentifizierungsfluss mit diesen Best Practices von Anfang an zu gestalten; das Vertrauen Ihrer Benutzer hängt davon ab.