II.1 iOS Security – Erklären Sie wichtigsten Komponenten der System Security, Encryption und App Security
a. System Security
System Security auf iOS beginnt mit der Hardware und setzt sich bis zur Softwareebene fort. Ziel: sicherstellen, dass das Betriebssystem & Apps in einer sicheren Umgebung operieren.
Secure Boot: iOS-Geräte verwenden einen sicheren Boot-Prozess, der sicherstellt, dass nur von Apple signierte und vertrauenswürdige Betriebssystemsoftware beim Start geladen wird. Dieser Prozess verhindert das Laden von modifizierter oder nicht autorisierter Software.
Hardware-Sicherheitsfunktionen: Apple verwendet spezielle Chips wie Secure Enclave, der biometrische Daten und kryptografische Schlüssel sicher speichert/verarbeitet, isoliert vom Hauptprozessor.
Softwareintegritätsschutz: Technologien wie Code Signing und Runtime Integrity Checks stellen sicher, dass Apps & Systemsoftware während der Laufzeit nicht manipuliert werden.
Permission System: iOS fordert Benutzer auf, Apps Zugriff auf bestimmte Informationen oder Hardwarefunktionen zu gewähren, wodurch die Kontrolle über die Privatsphäre verstärkt wird.
b. Encryption
Verschlüsselung ist ein fundamentaler Aspekt der iOS-Sicherheit, der dazu dient, Daten sowohl im Ruhezustand als auch während der Übertragung zu schützen.
Datenverschlüsselung im Ruhezustand: iOS-Geräte verschlüsseln automatisch alle Daten im Speicher, indem sie den Benutzerpasscode mit einer Geräte-spezifischen Hardware-Schlüssel kombinieren. Ohne die korrekte Passcode-Eingabe sind die Daten unzugänglich.
File-Level Encryption: iOS verwendet unterschiedliche Schlüssel für verschiedene Datenarten, was bedeutet, dass selbst wenn ein Schlüssel kompromittiert wird, nicht alle Daten des Geräts gefährdet sind.
Verschlüsselung bei der Übertragung: iOS sichert die Datenübertragung durch die Verwendung von Standardverschlüsselungsprotokollen wie TLS, um die Kommunikation zwischen dem Gerät und dem Internet oder zwischen Apps zu schützen.
c. App Security
App Security in iOS bezieht sich auf die Mechanismen, die sicherstellen, dass Apps sicher sind und keine Sicherheitsbedrohungen für das Gerät oder die Daten des Benutzers darstellen.
App Store Review: Jede App muss einen Überprüfungsprozess durchlaufen, bevor sie im App Store verfügbar ist, um sicherzustellen, dass sie den Sicherheits- und Datenschutzstandards von Apple entspricht.
Sandboxing: Jede App wird in einer “Sandbox” ausgeführt, einer eingeschränkten Umgebung, die verhindert, dass Apps auf Daten anderer Apps oder auf das System zugreifen.
API-Sicherheit: iOS stellt sicher, dass Apps nur sichere APIs verwenden, die den Zugriff auf kritische Systemfunktionen oder Benutzerdaten kontrollieren.
Exploit-Mitigations: iOS verwendet Techniken wie Address Space Layout Randomization (ASLR) und Non-Executable Memory, um gängige Exploit-Techniken zu erschweren.
II.2 Pentesting Prozess bei Mobilen Applikationen – Erklären Sie den Ablauf eines Mobile App Pentests nach OWASP
a. Vorbereitung und Planung
Tools = Jira, Trello
Best Practice = Klare Definition der Testziele, Festlegung des Umfangs, Erstellung eines Testplans und Zuweisung von Ressourcen
b. Bedrohungsmodellierung und Risikobewertung
Tools = MS Threat Modeling Tool, OWASP Threat Dragon
Best Practice = Identifizierung potenzieller Bedrohungen durch Analyse der Anwendungsarchitektur, des Datenflusses und der Angriffsszenarien
c. Reconnaissance und Information Gathering
Tools = Nmap, Shodan, Wireshark
Best Practice = Erfassung von Informationen über die mobile Anwendung, einschließlich ihrer APIs, Web-Services, Plattformen und Versionen
d. Analyse der Angriffsfläche
Tools = Reverse-Engineering-Tools wie JADX, Apktool oder Hopper Disassembler
Best Practice: Untersuchung der Client-seitigen und Server-seitigen Angriffsflächen, einschließlich Identifizierung von Authentifizierungs- und Autorisierungsmechanismen
e. Exploitation
Tools = Metasploit, Burp Suite oder OWASP ZAP
Best Practice: Durchführung von manuellen und automatisierten Angriffen, um Schwachstellen zu identifizieren und zu exploitieren, einschließlich Überprüfung von Session-Management, Datenverschlüsselung und Client-Side-Sicherheitsmechanismen
f. Reporting und Empfehlungen
Tools = Microsoft Word, Markdown, LaTeX
Best Practice: Dokumentation aller identifizierten Schwachstellen, ihrer Auswirkungen und Empfehlungen zur Behebung und Verbesserung der Sicherheit der mobilen Anwendung(en)
g. Nachbereitung und Follow-up
Tools = Confluence, SharePoint oder Google Docs
Best Practice: Überprüfung der Sicherheitsmaßnahmen & Verbesserungen, sowie kontinuierliche Aktualisierung des Bedrohungsmodells & Risikobewertung für zukünftige Pentests
// ChatGPT
„Ich erkläre den Pentest-Prozess anhand einer typischen mobilen Banking-App.“
⸻
„Wir definieren den Testumfang – z. B. Android und iOS, nur App oder auch Backend. Dann erstellen wir einen Testplan mit Tools wie Jira oder Trello.“
✅ Ziel: Klarheit über was getestet wird, wer was macht und wann.
⸻
„Ich analysiere die Architektur und Datenflüsse. Wo sind mögliche Schwachstellen? Zum Beispiel: ungesicherte Login-Übertragung oder Chat-Funktion.“
✅ Tools: OWASP Threat Dragon oder MS Threat Modeling Tool.
⸻
„Ich sammele Infos über die App, z. B. verwendete APIs, Server, Ports – mit Tools wie Nmap, Wireshark oder Shodan.“
✅ Beispiel: Ich finde eine öffentlich erreichbare API auf Port 8080.
⸻
„Ich dekompiliere die App mit JADX oder Apktool, prüfe den Code auf Schwachstellen – z. B. hartcodierte API-Keys oder unsichere Speicherung.“
✅ Beispiel: Ich finde im Code einen API-Schlüssel im Klartext.
⸻
„Ich führe manuelle und automatisierte Angriffe durch – z. B. mit Burp Suite oder ZAP. Ich teste Authentifizierung, Session-Handling usw.“
✅ Beispiel: Mit Burp Suite kann ich Daten eines anderen Nutzers abfragen (IDOR).
⸻
„Ich dokumentiere alle Funde, Risiken und gebe Empfehlungen – zum Beispiel in Word oder Markdown.“
✅ Beispiel: Empfehlung – API-Schlüssel nicht im Code speichern, sondern sicher auslesen.
⸻
„Ich überprüfe, ob die Schwachstellen behoben wurden, aktualisiere das Bedrohungsmodell und mache Vorschläge zur Verbesserung.“
✅ Tools: Confluence, Google Docs, SharePoint
II.3 Android Security – Erklären sie die wichtigsten Security Features von Android (Sandboxing, App Signaturen, Permissions, Verschlüsselung)
Sandboxing: Die App-Sandbox legt fest, auf welche Systemressourcen die Anwendung zugreifen darf. Ein Angreifer kann nur Aktionen ausführen, die in der Sandbox definiert sind.
Jede App ist in ihrer eigenen Sandbox isoliert und Apps können nur auf ihre eigenen Ressourcen zugreifen.
Der Zugriff auf sensible Ressourcen hängt von den Rechten der Anwendung ab.
Bei Installation wird neuer Linux-Benutzer für diese Anwendung erstellt, Sandbox wird von Linux enforced. Jeder App wird bei der Installation eine eindeutige UserID zugewiesen und läuft in einem separaten Prozess. Jede Anwendung hat einen privaten Datenordner.
Apps können nicht miteinander kommunizieren.
Annahme: Prozess möchte eine Datei auf der Festplatte speichern.
Der Prozess hat keinen Zugriff auf die physische Festplatte (zu gefährlich), sondern muss das Betriebssystem fragen. Der Entwickler verwendet High-Level-APIs. Sandbox = Security Boundary.
App Signaturen: App Signaturen dienen der Integrität und Authentizität.
Jede Android-App wird mit einem eindeutigen digitalen Zertifikat signiert, das vom Entwickler erstellt wird. Diese Signatur dient als Identifikationsmerkmal für die App und ermöglicht es dem Android-Betriebssystem, die Echtheit der App zu überprüfen und sicherzustellen, dass sie nicht manipuliert wurde.
Die wichtigsten Aspekte der Android App Signaturen sind:
- Identitätsnachweis (für App und Entwickler),
- Integritätsprüfung (auf Manipulation während Download und Installation),
- Sicherheitsüberprüfung (für Updates und Aktualisierungen)
- Vertrauenswürdigkeit
Permissions: Berechtigungen, die von Android-Apps angefordert werden, um auf bestimmte Funktionen oder Daten des Geräts zuzugreifen. Diese Berechtigungen werden vom Benutzer genehmigt, wenn die App installiert wird, und dienen dazu, die Privatsphäre und Sicherheit des Benutzers zu schützen, indem der Zugriff auf sensible Daten und Funktionen eingeschränkt wird.
Die wichtigsten Aspekte der Permissions sind:
- Datenschutz (Apps sollen z.B. nur auf diejenigen Daten zugreifen können, für die sie explizit die entsprechenden Berechtigungen erhalten haben),
- Sicherheit (Permissions verhindern, dass bösartige oder schädliche Apps unbefugt auf sensible Daten oder Funktionen des Geräts zugreifen),
- Berechtigungsmodelle (Android verwendet verschiedene Berechtigungsmodelle, um den Zugriff auf unterschiedliche Arten von Daten und Funktionen zu steuern. Beispielsweise gibt es normale Berechtigungen, die automatisch gewährt werden, wenn die App installiert wird, und es gibt auch gefährliche Berechtigungen, für die der Benutzer explizit zustimmen muss. Seit Android 6.0 „Marshmallow“ wird das sogenannte “Runtime Permissions” eingeführt, das den Benutzer dazu auffordert, Berechtigungen zu erteilen, wenn sie zum ersten Mal benötigt werden, anstatt alle Berechtigungen im Voraus bei der Installation zu erteilen.),
- Berechtigungsverwaltung (ermöglicht es Benutzern, Berechtigungen zu widerrufen oder einzuschränken, wenn sie das Gefühl haben, dass eine App zu viele Berechtigungen hat oder wenn sie Bedenken hinsichtlich der Privatsphäre haben.)
Verschlüsselung: Android bietet Funktionen zur Verschlüsselung von Daten auf dem Gerät, einschließlich persönlicher Dateien, Anwendungsdaten und Systemdaten. Wenn die Datenverschlüsselung aktiviert ist, werden die Daten mit einem kryptografischen Schlüssel verschlüsselt, der nur dem autorisierten Benutzer bekannt ist. Dadurch wird sichergestellt, dass selbst wenn das Gerät physisch gestohlen oder verloren geht, die Daten nicht ohne Autorisierung zugänglich sind.
Die wichtigsten Aspekte der Verschlüsselung sind:
- SSL/TLS-Verschlüsselung (Android unterstützt die Verwendung von SSL (Secure Sockets Layer) und TLS (Transport Layer Security) für die Verschlüsselung von Daten, die über das Internet übertragen werden, wie zum Beispiel Webseitenzugriffe, E-Mails und andere Netzwerkkommunikation. Diese Verschlüsselungstechnologien sorgen dafür, dass die Daten während der Übertragung zwischen dem Gerät und dem Server sicher und privat bleiben, indem sie vor Abhören und Manipulation schützen.),
- File-Based Encryption (FBE) (Ab Android 7.0 „Nougat“ verwendet Android File-Based Encryption (FBE), um die Verschlüsselung von Benutzerdaten zu verbessern. Mit FBE werden verschiedene Benutzerdaten separat verschlüsselt und entsperrt, wodurch ein besserer Schutz und eine bessere Verwaltung der Datenintegrität und des Datenschutzes erreicht werden.),
- Hardwarebeschleunigte Verschlüsselung (Moderne Android-Geräte verfügen häufig über spezielle Hardwarekomponenten, die die Verschlüsselung beschleunigen und die Leistung beeinträchtigen können. Durch die Verwendung von Hardwarebeschleunigung wird die Verschlüsselung effizienter und wirksamer, ohne die Benutzererfahrung zu beeinträchtigen.
II.4 Als CISO eines Unternehmens haben Sie ein Pentesting-Budget für 10 Personentage. Wie wägen Sie ab, ob Sie den externen Perimeter oder die interne AD-Infrastruktur testen, oder ein Red Teaming durchführen lassen?
Ein Red Teaming ist mit dieser begrenzten Anzahl von Personentagen eher auszuschließen. Ein Red Teaming ähnelt einen Black-Box-Test und ist daher sehr zeitintensiv; diese Methode eignet sich, um einen einzelnen Angriffspfad oder das Verhalten eines Blue Teams zu untersuchen.
Ob externe Perimeter oder interne AD-Infrastruktur getestet werden sollen, hängt von den Details ab. Externes eignet sich, wenn viele Systeme online erreichbar sind und/oder nicht von Security-Controls erfasst werden. Wenig Findings, Konzentration auf „Low hanging fruits“.
AD ist grundsätzlich die Schaltzentrale, wenn diese fällt, fällt alles (auch geschäftskritische Apps). Viel Fehlerpotenzial, viele Findings.
Ist nur meistens abgeschottet und braucht zentralen Eintrittsvektor (z.B. Phishing), bzw. Anti-Virus Bypass.
///// Alternative Antwort
Bei dieser begrenzten Anzahl von Tagen kommt es auf das Unternehmen und dessen wichtigsten/schützenswertesten Assets an.
Wenn wir jedoch von einem herkömmlichen Unternehmen mit einem AD (zur Authentifizierung und Authorisierung) ausgehen, würde ich ein AD Audit empfehlen.
Folgende Gründe sprechen dafür:
- Jeder Nutzer meldet sich über das AD an
- Eine Kompromittierung des ADs (gar als Admin) wäre eine Katastrophe (siehe Frage zuvor)
- Durch die weite verbreiteten Einsatz des Active Directories ist es auch für Angreiffer sehr attraktiv
- Aufgrund der langen Backward-Kompatiblität einer AD Infrastruktur können Altlasten in Form von Fehlkonfigurationen und veralteten Versionen vorkommen
- Eine AD-Infrastruktur ist sehr komplex und bietet viele möglichkeiten für Fehlkonfigurationen wie zum Beispiel:
- WSUS (Beispiel: Unverschlüsselte Updates)
- AD CS (Beispiel: ESC1 - ESC14)
- WDS (Beispiel: Information Disclosure von Clientkonfigurationen)
- AD DS (Beispiel: Informationen in GPOs, Userdescriptions, Gruppen, … )
- Sharerechte und zugängliche, sensible Daten
- DNS (Beispiel: unsichere dynamische Updates)
- schwache PW Richtlinien
- Fehlendes Signing (SMB/LDAP) (Beispiel: MitM wird ermöglicht)
- Falsch konfigurierte Delegations
- Resource-Based Constrained Delegation
- Unconstrained Deligation
- Constrained Deligation
Für ein Red Teaming sind 10 PT eindeutig zu wenig, außer man beschränkt den Scope ausreichend. Dann stellt sich die Frage ob sich nicht ein detailierte Pentest einer einzelnen Applikation anbieten würde.
II.5 Welche Auswirkungen könnte es haben, wenn der Domänenadministrator einer AD-Infrastruktur kompromittiert wird?
Der Domänenadministrator hat im Wesentlichen die höchsten Berechtigungen in der AD-Umgebung und kann daher nahezu alle Aspekte des Netzwerks verwalten und steuern. Wenn ein Angreifer Zugriff auf das Domänenadministratorkonto erhält, kann er eine vollständige Kontrolle über das Netzwerk erlangen. Dies ermöglicht es ihm, Benutzerkonten zu erstellen, zu löschen oder zu ändern, Sicherheitsrichtlinien zu umgehen, Datenbanken zu manipulieren, kritische Systeme zu kompromittieren und vieles mehr.
Weitere Aspekte: Privilege Escalation, Data Exfiltration, Sabotage, Einrichtung von Backdoors
// Alternative Antwort
ist ein Totalschaden….
Auswirkungen der Kompromittierung eines Domänenadministrators:
Präventive Maßnahmen
Reaktive Maßnahmen
II.6 Welche Vorteile könnte es für den Auftraggeber eines Pentests mit sich bringen, den Test in einem White- oder Grey-Box-Ansatz durchzuführen, im Gegensatz zu einem Black-Box-Ansatz?
Bei einem White-Box-Test ist das Zielsystem (auch Source Code) bekannt und daher ist eine sehr fokussierte Testung möglich. Ein Grey Box ist eine Mischung aus White und Black Box, d.h. das Zielsystem ist teilweise bekannt.
Black Box ist der klassischen Hacker-Attacke am ähnlichsten, d.h. vom Zielsystem ist nichts bekannt. Das macht den Black-Box-Test zeitintensiv (und damit teurer) und bezüglich der Results eher oberflächlich. Die beiden anderen Formen erlauben spezifisches Überprüfen.
//// Alternative Antwort
##### White-Box-Ansatz
Beschreibung:
- Bei einem White-Box-Pentest erhalten die Tester umfassende Informationen über die Zielumgebung. Dies kann Quellcode, Netzwerkdiagramme, Konfigurationsdetails und Anmeldeinformationen beinhalten.
Merkmale:
- Transparenz: Die Tester haben vollen Zugriff auf alle Informationen über die Infrastruktur.
- Tiefenanalyse: Ermöglicht eine detaillierte Analyse und das Auffinden von Schwachstellen, die sonst schwer zu entdecken wären.
- Effizienz: Kann schneller durchgeführt werden, da die Tester nicht erst die Architektur und Konfiguration der Systeme herausfinden müssen.
Vorteile:
- Gründliche und umfassende Bewertung der Sicherheit.
- Identifizierung tiefliegender Schwachstellen.
- Möglichkeit zur Prüfung von sicherheitsrelevanten Implementierungsdetails und Konfigurationen.
Nachteile:
- Nicht repräsentativ für einen echten Angriff von außen.
- Potenzieller Bias durch Vorwissen.
Beschreibung:
- Bei einem Grey-Box-Pentest erhalten die Tester teilweise Informationen über die Zielumgebung. Dies kann Zugang zu bestimmten Benutzerkonten oder allgemeinen Netzwerkübersichten beinhalten, ohne vollständigen Zugang zu detaillierten Informationen.
Merkmale:
- Teilweise Transparenz: Die Tester haben begrenzte Kenntnisse über die Zielumgebung.
- Kompromiss: Ein Mittelweg zwischen White-Box und Black-Box, der sowohl eine effektive als auch realistische Bewertung ermöglicht.
- Realismus: Spiegelt oft die Situation wider, in der ein Angreifer bereits einige Informationen über das Netzwerk hat (z.B. durch Social Engineering).
Vorteile:
- Balance zwischen Detailtiefe und Realismus.
- Effizienter als Black-Box, aber realistischer als White-Box.
- Kann die Fähigkeit zur Erkennung von Schwachstellen in verschiedenen Sicherheitsstufen testen.
Nachteile:
- Nicht so gründlich wie ein White-Box-Test.
- Erfordert sorgfältige Planung, um die richtige Menge an Informationen bereitzustellen.
Beschreibung:
- Bei einem Black-Box-Pentest haben die Tester keinerlei Vorwissen über die Zielumgebung. Sie müssen die Systeme und Netzwerke wie ein externer Angreifer erkunden und testen.
Merkmale:
- Keine Transparenz: Die Tester beginnen ohne Informationen über die Zielumgebung.
- Realismus: Simuliert einen echten externen Angriff.
- Entdeckungsphase: Die Tester verbringen viel Zeit damit, Informationen über die Zielumgebung zu sammeln.
Vorteile:
- Hoher Realitätsgrad, da es einen echten externen Angriff simuliert.
- Hilfreich zur Bewertung der externen Sicherheit und der Fähigkeit des Sicherheitsteams, Angriffe zu erkennen und zu reagieren.
Nachteile:
- Zeitaufwändig, da die Tester zunächst die Umgebung erkunden müssen.
- Möglicherweise weniger gründlich, da die Tester ohne Vorwissen arbeiten.
Einsatzbereiche:
- White-Box: Geeignet für interne Tests, wenn eine tiefgehende Analyse gewünscht ist und es darum geht, alle potenziellen Schwachstellen zu identifizieren.
- Grey-Box: Ideal für Tests, bei denen eine gewisse realistische Angriffsperspektive gewünscht ist, aber auch eine effizientere Nutzung der Testzeit. Häufig verwendet für Anwendungen und Systeme, bei denen der Tester Zugang auf Benutzerebene hat.
- Black-Box: Bestens geeignet für die Simulation eines echten externen Angriffs, um die externen Verteidigungsmechanismen und die Erkennungs- und Reaktionsfähigkeit des Sicherheitsteams zu testen.
Beispielhafte Szenarien:
- White-Box: Test der internen AD-Infrastruktur, um tiefgehende Konfigurationsschwächen aufzudecken.
- Grey-Box: Test einer Webanwendung mit Benutzerzugang, um Schwachstellen zu finden, die ein authentifizierter Benutzer ausnutzen könnte.
- Black-Box: Externer Pentest eines öffentlichen Webservers, um zu prüfen, ob er für Angriffe von außen anfällig ist.
II.7 Erklären Sie das Need-to-Know-Prinzip, sowie das Prinzip der geringsten Privilegien (Principle of Least Privilege) und erläutern Sie, warum diese besonders bei der Vergabe von Domänenadministratoren-Berechtigungen eingehalten werden sollten.
Beide sind grundlegende Konzepte in der Informationssicherheit, die dazu dienen, den Zugriff auf sensible Informationen und Systeme zu kontrollieren und zu beschränken.
Need-to-Know-Prinzip: Dieses Prinzip besagt, dass ein Benutzer nur auf die Informationen oder Ressourcen zugreifen sollte, die für die Erfüllung seiner unmittelbaren Aufgaben oder Verantwortlichkeiten erforderlich sind. Mit anderen Worten, ein Benutzer sollte nur Zugriff auf diejenigen Daten oder Systeme haben, die er benötigt, um seine Arbeit zu erledigen, und nicht auf mehr.
Prinzip der geringsten Privilegien (Principle of Least Privilege): Dieses Prinzip besagt, dass einem Benutzer nur die minimalen Berechtigungen oder Privilegien gewährt werden sollten, die für die Ausführung seiner Aufgaben unbedingt erforderlich sind. Dies bedeutet, dass ein Benutzer nur über die Berechtigungen verfügen sollte, die unbedingt erforderlich sind, um seine Arbeit zu erledigen, und nicht über zusätzliche Berechtigungen, die nicht benötigt werden.
Durch die Beschränkung der Berechtigungen von Domänenadministratoren wird die Angriffsfläche für potenzielle Angriffe und Sicherheitsverletzungen reduziert. Ein Domänenadministrator mit übermäßigen Berechtigungen könnte unabsichtlich oder absichtlich Aktionen durchführen, die das Netzwerk gefährden könnten.
/// alternative Antwort
Das Need-to-Know-Prinzip (Bedarf-zu-wissen-Prinzip) stellt sicher, dass Personen oder Systeme nur auf die Informationen zugreifen dürfen, die sie für ihre Arbeit oder Funktion unbedingt benötigen.
Vorteile:
- Datensicherheit: Minimierung der Wahrscheinlichkeit, dass sensible Informationen in die falschen Hände geraten.
- Schutz vor Insider-Bedrohungen: Reduktion der Möglichkeit, dass interne Mitarbeiter Informationen missbrauchen.
- Kompromittierungsbegrenzung: Im Falle einer Datenpanne bleibt der Schaden begrenzt, da nicht alle Informationen zugänglich sind.
Das Prinzip der geringsten Privilegien besagt, dass jeder Benutzer, jedes Programm oder jeder Prozess nur die minimalen Berechtigungen erhalten sollte, die notwendig sind, um seine Aufgaben zu erfüllen.
Anwendung:
- Einsatzbereiche: Betriebssysteme, Datenbanken, Netzwerksicherheit, Zugriffssteuerung.
- Implementierung: Rollenbasierte Zugriffskontrollen (RBAC), spezifische Berechtigungszuteilung und regelmäßige Überprüfung und Anpassung der Berechtigungen.
Vorteile
- Sicherheit: Reduktion des Risikos, dass Benutzer oder Prozesse unbeabsichtigt oder absichtlich Systeme kompromittieren.
- Fehlerbegrenzung: Begrenzung der Auswirkungen von Fehlkonfigurationen oder Softwarefehlern.
- Verwaltbarkeit: Einfachere Verwaltung und Überprüfung von Berechtigungen.
II.8 Erläutern Sie, wie ein sicheres und starkes Passwort aussehen muss, damit es als Passwort-Hash in absehbaren Zeiträumen nicht geknackt werden kann. Erläutern Sie zudem, mittels welcher Hilfestellungen sich Benutzer diese merken oder verwalten können.
Länge: Ein sicheres Passwort sollte ausreichend lang sein, idealerweise mindestens 12 bis 16 Zeichen lang. Je länger das Passwort ist, desto länger braucht der Brute-Force-Angriff.
Komplexität: Das Passwort sollte aus einer Kombination von Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen bestehen. Durch die Verwendung verschiedener Zeichenarten wird die Komplexität des Passworts erhöht.
Zufälligkeit: Ein sicheres Passwort sollte möglichst zufällig sein und keine offensichtlichen Wörter, Phrasen oder persönliche Informationen enthalten. Zu vermeiden: “password”, “123456” oder Namen von Familienmitgliedern und Haustieren.
Einzigartigkeit: Verwenden Sie für jedes Konto oder jede Anwendung ein einzigartiges Passwort. Dadurch wird das Risiko minimiert, dass bei einem Kompromittierung eines Passworts alle anderen Konten ebenfalls gefährdet sind (Credential Stuffing).
Vermeidung von Wörtern/Mustern: Vermeiden Sie die Verwendung von Wörtern aus dem Wörterbuch, bekannten Phrasen oder einfachen Mustern wie “qwerty” oder “123456789”.
Folgende Hilfestellungen nutzen:
Passwort-Manager: Verwenden Sie einen Passwort-Manager, um sichere Passwörter zu generieren, zu speichern und zu verwalten. Ein Passwort-Manager kann starke, zufällige Passwörter für jedes Konto erstellen und speichern, wodurch Benutzer sich nur ein Hauptpasswort merken müssen, um auf ihre gespeicherten Passwörter zuzugreifen.
Passphrasen: Statt sichere Passwörter aus zufälligen Zeichen zu erstellen, können Benutzer auch Passphrasen verwenden. Passphrasen bestehen aus einer Reihe von Wörtern oder Wortgruppen, die zusammen eine leicht zu merkende Phrase bilden. Zum Beispiel könnte eine Passphrase “BananeBlauHimmel123!” lauten.
Mnemotechnische Hilfen: Benutzer können sichere Passwörter erstellen, indem sie sich an mnemotechnische Hilfen erinnern, die ihnen helfen, sich die Zeichenfolge zu merken. Zum Beispiel könnte die erste Zeile eines bekannten Gedichts als Mnemotechnik dienen, um eine Passphrase zu erstellen.
Regelmäßige Aktualisierung: Es ist wichtig, Passwörter regelmäßig zu aktualisieren, um die Sicherheit zu erhöhen. Passwort-Manager können Benutzer dabei unterstützen, sich regelmäßig neue, sichere Passwörter zu generieren und alte Passwörter zu aktualisieren.