Security by Obscurity liegt vor, wenn ein System hauptsächlich deshalb als sicher gilt, weil ein Angreifer seine Adresse, Funktionsweise oder Implementierung angeblich nicht kennt. Verbergen kann Aufwand erhöhen und automatisches Rauschen reduzieren. Es ist jedoch keine belastbare primäre Sicherheitskontrolle, sobald eine Offenlegung den gesamten Schutz aufhebt.
Woran erkennt man Security by Obscurity?
| Behaupteter Schutz | Fehlende eigentliche Kontrolle |
|---|---|
| Eine unbekannte Administrations-URL | Starke Authentifizierung und Autorisierung. |
| SSH oder Datenbank auf einem anderen Port | Zugriffsbeschränkung, sichere Anmeldung und gehärtete Konfiguration. |
| Undokumentierter API-Parameter | Serverseitige Berechtigungsprüfung für die Funktion. |
| Proprietärer Verschlüsselungsalgorithmus | Öffentlich geprüfte Kryptografie mit sicherem Schlüsselmanagement. |
| Unbekanntes internes Netz | Segmentierung und authentisierte Verbindungen. |
Die Kontrollfrage lautet: Bleibt das System angemessen geschützt, wenn Design, URL, Port und Quellcode morgen öffentlich werden? Ist die Antwort nein, hängt die Sicherheit zu stark von Obscurity ab.
Warum ist das Prinzip unzuverlässig?
Verborgene Details werden durch Suchmaschinen, DNS- und Zertifikatsdaten, Fehlermeldungen, Netzwerkscans, Client-Code oder Reverse Engineering sichtbar. Mitarbeitende und Dienstleister kennen sie ebenfalls; Dokumente, Backups und Repositories können nach außen gelangen. Ein Angreifer muss das Geheimnis nur einmal finden, während der Betreiber dauerhaft auf dessen Geheimhaltung angewiesen ist. Außerdem bleiben solche Annahmen oft ungetestet, weil die Organisation Auffindbarkeit mit Sicherheit verwechselt.
Ist Geheimhaltung grundsätzlich falsch?
Nein. Passwörter, private Schlüssel, Recovery-Codes und Sitzungstokens müssen geheim bleiben. Das ist kein problematisches Security by Obscurity, weil das Verfahren bekannt sein darf und der Schutz auf einem ausreichend starken, austauschbaren Geheimnis beruht. Auch unnötige Banner zu entfernen, interne Dokumentation nicht öffentlich zu stellen oder einen Administrationsdienst nicht im Internet anzubieten ist vernünftige Reduktion der Angriffsoberfläche.
Der Unterschied: Ein kryptografischer Schlüssel ist bewusst als Geheimnis entworfen, hat genügend Entropie, kann gewechselt werden und wird zusätzlich durch Zugriffskontrollen geschützt. Eine URL oder ein proprietäres Protokolldetail erfüllt diese Eigenschaften meist nicht.
Was ist Kerckhoffs’ Prinzip?
Kerckhoffs’ Prinzip fordert sinngemäß, dass ein kryptografisches System sicher bleiben soll, selbst wenn alles außer dem Schlüssel bekannt ist. Moderne Sicherheitsarchitektur überträgt diese Idee: Algorithmen, Protokolle und Kontrolllogik dürfen überprüfbar sein. Geheim bleibt der kleine, austauschbare Schlüssel – nicht das gesamte Design. Öffentliche Prüfung findet häufig Fehler, bevor ein Angreifer sie heimlich ausnutzt.
Wie wird aus Obscurity eine zusätzliche Schutzschicht?
- Zuerst Authentifizierung, Autorisierung, sichere Konfiguration, Verschlüsselung und Logging unabhängig umsetzen.
- Nicht benötigte Dienste, Metadaten und öffentliche Informationen bewusst entfernen.
- Verborgene Details als vergängliche Information behandeln und Offenlegung einplanen.
- Keine Sicherheitsentscheidung allein auf einen geheimen Pfad, Header, Dateinamen oder Client-Code stützen.
- Geheimnisse inventarisieren, sicher speichern, rotieren und nach Offenlegung widerrufen.
Wie wird das im Pentest bewertet?
Ein Penetrationstest betrachtet nicht nur, ob ein Endpunkt sofort auffindbar ist. Tester leiten Pfade aus JavaScript, mobilen Apps, DNS, Archiven und Fehlermeldungen ab und rufen Funktionen direkt auf. Eine versteckte Seite ohne Berechtigungsprüfung ist ein Autorisierungsfehler; ihre geringe Bekanntheit senkt höchstens die Wahrscheinlichkeit einer zufälligen Entdeckung. Die Behebung muss die fehlende Kontrolle ergänzen, nicht lediglich den Pfad erneut umbenennen.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.