nicht angemeldet
security by obscurity
Matthias Apsel
security by obscurity
Matthias Apsel
TS
JuliusHallo alle,
@beatovich hat folgenden Beitrag auf einer Diskussionsseite hinterlassen.
Zitat: Der Begriff security by obscurity bedeutet übersetzt so etwas wie Sicherheit durch Verschleierung und bezeichnet ein problematisches, weil technisch letzten Endes nicht sicheres Vorgehen.
Kommentar: Etwas mehr Nuance wäre angebracht. Obskuranz wird immer angewendet. Niemand ausser ich soll mein Passwort kennen. Und es ist letztlich die einzige Methode, der wir Vertrauen. Es geht also darum, Obskuranz an möglichst nicht angreifbare Methoden zu heften, wo die Wahrscheinlichkeit für Informations-Lecks auch am geringsten ist.
Im Fall von 'geheimen' Links sind gerade die Möglichkeiten von Informations-Lecks gross. Dazu kann es genügen, einen solchen Link zu bookmarken.
Bis demnächst
Matthias
-
hallo
Im Fall von 'geheimen' Links sind gerade die Möglichkeiten von Informations-Lecks gross. Dazu kann es genügen, einen solchen Link zu bookmarken.
Bis demnächst
MatthiasSo ein Mist, jemand hat meine geheime Seite entdeckt.
-
Hallo beatovich.
So ein Mist, jemand hat meine geheime Seite entdeckt.
Du musst deine feminine Seite nicht geheim halten.
MfG, at
-
-
Lieber Matthias,
Du „verschleierst“ Dein Passwort nicht, Du hältst es geheim. Ob beides unter „Obskuranz“ fällt, ist mir so was von Schnuppe. Aber im Englischen ist obscurity etwas anderes als secrecy.
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix,
Du „verschleierst“ Dein Passwort nicht, Du hältst es geheim. Ob beides unter „Obskuranz“ fällt, ist mir so was von Schnuppe. Aber im Englischen ist obscurity etwas anderes als secrecy.
Ja, genau richtig. Da warst du schneller als ich 😀
LG,
CK
-
-
Hallo Matthias,
Kommentar: Etwas mehr Nuance wäre angebracht. Obskuranz wird immer angewendet. Niemand ausser ich soll mein Passwort kennen. Und es ist letztlich die einzige Methode, der wir Vertrauen. Es geht also darum, Obskuranz an möglichst nicht angreifbare Methoden zu heften, wo die Wahrscheinlichkeit für Informations-Lecks auch am geringsten ist.
Im Fall von 'geheimen' Links sind gerade die Möglichkeiten von Informations-Lecks gross. Dazu kann es genügen, einen solchen Link zu bookmarken.
Tut mir leid, aber das ist totaler Bullshit. Ein Passwort ist ein Geheimnis (Secret), keine Verschleierung (Obscurity).
Security by Obscurity bezeichnet ein Vorgehen, bei dem man sich darauf verlässt, dass ein potentieller Angreifer einen Zugriff nicht erlangt, weil er nicht genau weiß, wie das System aufgebaut ist: etwa habe ich eine URL, die es erlaubt etwas zu löschen, aber sie ist nur dem Admin bekannt. Die Annahme, dass niemand diesen Link kennt und es deshalb sicher ist, ist Security by Obscurity. Die Praxis hat gezeigt, dass diese Annahme prinzipiell nicht als gegeben anzunehmen ist. Dieses Konzept funktioniert nicht. Stattdessen geht man davon aus, dass der Angreifer potentiell jedes Detail des Systems kennt. Diese Annahme führt zu einer paranoideren Denkweise und deshalb dazu, dass man Zugriffsrechte genauer prüft, Zugriffe schützt und ähnliches.
Das Obscurity hat mit Geheimnissen (im Sinne von Keys und Passwörtern) überhaupt gar nichts zu tun.
LG,
CK-
hallo Wenn es mir erlaubt ist, brute-force anzuwenden, ist es mir egal, ob jemand einen semantischen Unterschied zwischen Obskuranz und Geheimnis macht.
-
Hello,
Wenn es mir erlaubt ist, brute-force anzuwenden, ist es mir egal, ob jemand einen semantischen Unterschied zwischen Obskuranz und Geheimnis macht.
Das erinnert mich an eine Aufgabe, die ich seit langem auf dem Zettel habe.
Wie kann ich auf dem Server feststellen, dass Session-Tokens "durchgetickert" werden? Ist bei PHP und dem inzwischen erheblich erhöhten Wertebeeich von Session-Tokens unwahrscheinlich, dass jemand trifft, aber es ist nicht unmöglich!
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
hallo
Wie kann ich auf dem Server feststellen, dass Session-Tokens "durchgetickert" werden? Ist bei PHP und dem inzwischen erheblich erhöhten Wertebeeich von Session-Tokens unwahrscheinlich, dass jemand trifft, aber es ist nicht unmöglich!
Ich habe auf einer Seite for einem Jahrzehnt einen One-Time-Key verwendet. Wurde ein veralteter Key wiederverwendet, wurde eine Session gekillt. Ein Diebstahl einer Session war also nur möglich in dem seltenen Fall, wo exakt das letzte aktive Token vom Angreifer zuerst benutzt wurde, und der Angegriffene selber nie mehr sein Token angesendet hat. Eigentlich ist der wichtige Punkt: welche Konsequenzen haben gescheiterte Challanges.
-
Hello,
Eigentlich ist der wichtige Punkt: welche Konsequenzen haben gescheiterte Challanges.
in diesem Fall will ich die Fehlversuche ins Konzept von fail2ban einbauen. Das bedeutet aber, dass jeder Fehlversuch auch einen entsprechenden Log-Eintrag benötigt, der dann von fail2ban ausgewertet werden kann.
Da in mit Session-Token authorisierenden Systemen meistens über eine zentrale index.php läuft, müsste die also für einen Log-Eintrag sorgen. Bzw. das Modul, das die Authentifizierung und Authorisierung durchführt, müsste den Logeintrag erstellen.
Dann müssten meiner Logik nach mitgesandte Session-Cookies, für die es keine Sessiondatei gibt, Logeinträge verursachen und Anmelde-Fehlversuche auch, wenn also schon eine Sessiondatei existiert, aber die Anmeldedaten nicht stimmen.
Durchrutschen werden dann selbstverständlich wieder diejenigen, die jeden Request mit einer anderen IP absenden, was uns ja im Zeitalter von IPv6 direkt bevorstehen könnte.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
hallo
Durchrutschen werden dann selbstverständlich wieder diejenigen, die jeden Request mit einer anderen IP absenden, was uns ja im Zeitalter von IPv6 direkt bevorstehen könnte.
IPv6, quic, SPDY und HTML/2 alle bieten neue Möglichkeiten und Schwächen.
Eine ähnliche von meinem Hoster beriebene Software hat mich selber regelmässig über Stunden daran gehindert meine Site zu administrieren. Deshalb sollte man da sehr vorsichtig sein, damit's nicht ein Schuss in den Fuss wird.
-
Hallo beatovich,
Durchrutschen werden dann selbstverständlich wieder diejenigen, die jeden Request mit einer anderen IP absenden, was uns ja im Zeitalter von IPv6 direkt bevorstehen könnte.
IPv6, quic, SPDY und HTML/2 alle bieten neue Möglichkeiten und Schwächen.
IPv6 löst das Problem der fehlenden IP-Adressen nachhaltig. Dass man sich die Adressen nicht merken kann, liegt in der Natur der Sache, und dass die Umstellung nicht schneller geht, ist nicht das Problem des Standards. SPDY ist veraltet und von HTTP/2 (ich denke mal, dass du das meintest) abgelöst worden.
Jede neue Technik hat ihre Vor- und Nachteile. Wegen letzterer werden viele Standards auch nicht eingesetzt, man denke da an DNSSEC, und warten auf ihre Ablösung. Technologien, die von der breiten Masse benutzt werden, haben sich meist bewährt.
Eine ähnliche von meinem Hoster beriebene Software hat mich selber regelmässig über Stunden daran gehindert meine Site zu administrieren. Deshalb sollte man da sehr vorsichtig sein, damit's nicht ein Schuss in den Fuss wird.
Vorsichtig sollte man aber auch damit sein, nicht zu viele Login-Versuche zuzulassen und dies für Benutzeraccounts und IPs (nur auf IPs ist eine schlechte Idee, die Nutzern eines Uni- oder Schul-Netzwerks würden sich sehr darüber freuen 😟) auf eine bestimmte Anzahl von Versuchen zu beschränken.
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
hallo
HTTP/2 (ich denke mal, dass du das meintest) .
grmpfl klar ;)
Jede neue Technik hat ihre Vor- und Nachteile. Wegen letzterer werden viele Standards auch nicht eingesetzt, man denke da an DNSSEC, und warten auf ihre Ablösung. Technologien, die von der breiten Masse benutzt werden, haben sich meist bewährt.
Sicher kann man sagen, dass viel benutzte Technik oft angegriffen und deshalb noch öfters gepatcht wird.
Interessant fand ich, dass an der Defcon Passworte aus Mobiles von Passanten beim vorbeigehen an einen Schirm projetziert wurden. Der überweigende Konsens aller Anwesenden daraufhin war es, das Mobile ganz auszuschalten.
Vorsichtig sollte man aber auch damit sein, nicht zu viele Login-Versuche zuzulassen und dies für Benutzeraccounts und IPs (nur auf IPs ist eine schlechte Idee, die Nutzern eines Uni- oder Schul-Netzwerks würden sich sehr darüber freuen 😟) auf eine bestimmte Anzahl von Versuchen zu beschränken.
Das Selfhtml Wiki definiert hier die Anzahl von Versuchen mit 1 und die verhängte Sperre dauert 24 Stunden.
-
Hello,
Vorsichtig sollte man aber auch damit sein, nicht zu viele Login-Versuche zuzulassen und dies für Benutzeraccounts und IPs (nur auf IPs ist eine schlechte Idee, die Nutzern eines Uni- oder Schul-Netzwerks würden sich sehr darüber freuen 😟) auf eine bestimmte Anzahl von Versuchen zu beschränken.
Abgewiesene Logins sind nicht das Thema, sondern Session-Klau mittels erratener Session-Tokens. Also in PHP gesprochen, einfach nur PHPSESSID senden, was das Teug hält, bis eine passt. Derartige Requestbursts sind bisher nicht abgefangen.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
Abgewiesene Logins sind nicht das Thema, sondern Session-Klau mittels erratener Session-Tokens. Also in PHP gesprochen, einfach nur PHPSESSID senden, was das Teug hält, bis eine passt. Derartige Requestbursts sind bisher nicht abgefangen.
Ich habe vor nicht sehr langer Zeit ein Video gesehen, wie man PHP Sessions angreift. Der Autor war ehemals bekannt als Verbreiter des SAMY Wurms auf MySpace. Er zeigte im Video wie die beeindruckende Bit-Zahl des Tokens wirklich zusammenschrumpft auf wenige Bits.
-
Hallo beatovich,
Ich habe vor nicht sehr langer Zeit ein Video gesehen, wie man PHP Sessions angreift. Der Autor war ehemals bekannt als Verbreiter des SAMY Wurms auf MySpace. Er zeigte im Video wie die beeindruckende Bit-Zahl des Tokens wirklich zusammenschrumpft auf wenige Bits.
Dann greift er aber wohl eine Seite ein, die schlecht konfiguriert ist (die Länge des Session-Tokens ist in der php.ini einstellbar) oder eine unzuverlässige Quelle für Zufallszahlen benutzt.
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
Hello,
Dann greift er aber wohl eine Seite ein, die schlecht konfiguriert ist (die Länge des Session-Tokens ist in der php.ini einstellbar) oder eine unzuverlässige Quelle für Zufallszahlen benutzt.
Selbst wenn man wegen der Kompatibilität mit seinen alten Datenbankmodulen (Spaltenbreite 32), die Länge der SessionID bei 32 Digits belässt, ist die Anzahl der Werte pro Stelle auf 64 gestiegen. Früher war das nur ein md5-Hash.
Trotzdem ist das die angreifbarste Stelle im Sessiokonzept, weil sie von den allermeisten Systemen, incl. Webserver und seinen Sicherheitsfeatures nicht beachtet wird. Und das betrifft nicht nur PHP-Applikationen!
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
Hallo Tom,
Dann greift er aber wohl eine Seite ein, die schlecht konfiguriert ist (die Länge des Session-Tokens ist in der php.ini einstellbar) oder eine unzuverlässige Quelle für Zufallszahlen benutzt.
Selbst wenn man wegen der Kompatibilität mit seinen alten Datenbankmodulen (Spaltenbreite 32), die Länge der SessionID bei 32 Digits belässt, ist die Anzahl der Werte pro Stelle auf 64 gestiegen. Früher war das nur ein md5-Hash.
PHP benutzt dafür doch keine Datenbank, sondern legt das als Dateien ab, oder liege ich da falsch? Wenn man aus Gründen der Kompatibilität Abschläge an der Sicherheit machen möchte, sollte man lieber erst einmal das alte Gerümpel ausmisten oder modernisieren.
Dann ist es aufgrund der vielen möglichen Session-Tokens extremst unwahrscheinlich, dass das mit Bruteforce funktioniert.
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
Hello,
PHP benutzt dafür doch keine Datenbank, sondern legt das als Dateien ab, oder liege ich da falsch? Wenn man aus Gründen der Kompatibilität Abschläge an der Sicherheit machen möchte, sollte man lieber erst einmal das alte Gerümpel ausmisten oder modernisieren.
Das habe ich auch nicht gemeint. Ich lege Session-Tokens in einer DB ab.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
Hallo Tom,
Ich lege Session-Tokens in einer DB ab.
... die von PHP erzeugten oder andere?
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
Hello,
Ich lege Session-Tokens in einer DB ab.
... die von PHP erzeugten oder andere?
Die von und die für PHP erzeugten.
Für mein Image-Upload-Skript erzeuge ich selber welche für den Temporärspeicher für die neuen, ungeprüften Bilder. Die bekommen eigene "Sessiondateien". Ich benutze da eigentlich nur den Meschanismus des GC, damit ich später nicht lauter Dateileichen habe.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
Hallo Tom,
Ich lege Session-Tokens in einer DB ab.
... die von PHP erzeugten oder andere?
Die von und die für PHP erzeugten.
Für mein Image-Upload-Skript erzeuge ich selber welche für den Temporärspeicher für die neuen, ungeprüften Bilder. Die bekommen eigene "Sessiondateien". Ich benutze da eigentlich nur den Meschanismus des GC, damit ich später nicht lauter Dateileichen habe.
... und warum verwendest du dann keine Datenbank, die mit den „sicheren“ Tokens klarkommt statt drum herum zu basteln (hört sich für mich danach an)?
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
Hello,
... und warum verwendest du dann keine Datenbank, die mit den „sicheren“ Tokens klarkommt statt drum herum zu basteln (hört sich für mich danach an)?
Das führt jetzt zu weit. Mir ging es nur darum, warum man nicht einfach an einer Stelle etwas ändern kann, wenn man nicht weiß, wo es sich noch überall auswirken kann. Die meisten Frameworks würden da Kotzen, wenn Du einfach so die Länge des Sessiontokens erhöhen würdest.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
-
-
-
-
-
-
hallo
Dann greift er aber wohl eine Seite ein, die schlecht konfiguriert ist (die Länge des Session-Tokens ist in der php.ini einstellbar) oder eine unzuverlässige Quelle für Zufallszahlen benutzt.
Die Stärke eines Session Tokens hängt aber nicht von der Länge eines Tokens ab, sondern von der Komplexität der verwendeten Entropie.
-
Hallo beatovich,
Dann greift er aber wohl eine Seite ein, die schlecht konfiguriert ist (die Länge des Session-Tokens ist in der php.ini einstellbar) oder eine unzuverlässige Quelle für Zufallszahlen benutzt.
Die Stärke eines Session Tokens hängt aber nicht von der Länge eines Tokens ab, sondern von der Komplexität der verwendeten Entropie.
... die wiederum davon abhängt, wie groß der Ergebnisraum ist und den schränkt man dann doch durch die Konfigurationseinstellung dann doch wieder ein, oder sehe ich das falsch?
; Set session ID character length. This value could be between 22 to 256. ; Shorter length than default is supported only for compatibility reason. ; Users should use 32 or more chars. ; http://php.net/session.sid_length ; Default Value: 32 ; Development Value: 26 ; Production Value: 26 session.sid_length = 48Wenn ich den Token versuche zu knacken, fällt mir das doch nicht leicht, wenn der Zufallszahlengenerator Zahlen mit hoher Entropie erzeugt und der Token lang genug ist, weil ich den ja zu erraten versuche!
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)-
hallo
Wenn ich den Token versuche zu knacken, fällt mir das doch nicht leicht, wenn der Zufallszahlengenerator Zahlen mit hoher Entropie erzeugt und der Token lang genug ist, weil ich den ja zu erraten versuche!
Gegenstand des von mir angedeuteten Videos war eben, dass die verwendete Entropie tatsächlich für die Bitlänge, ergo scheinbare Bitstärke gar nicht angemessen war.
Nur als Beispiel: Wenn ich eine Zeitangabe als Teil der Entropie verwende, was glaubst du dann, wie relevant Jahr, Monat, Tag, Stunde oder gar Minute sind?
-
Hallo beatovich,
Wenn ich den Token versuche zu knacken, fällt mir das doch nicht leicht, wenn der Zufallszahlengenerator Zahlen mit hoher Entropie erzeugt und der Token lang genug ist, weil ich den ja zu erraten versuche!
Gegenstand des von mir angedeuteten Videos war eben, dass die verwendete Entropie tatsächlich für die Bitlänge, ergo scheinbare Bitstärke gar nicht angemessen war.
Da PHP aber meistens auf einem Linux-System laufen wird, dass einen ordentlichen Zufallsgenerator haben sollte, ist das doch kein allzu großes Problem für PHP-Session-IDs, oder? – Vorausgesetzt natürlich, dass da niemand die Konfiguration kaputt gemacht hat.
Nur als Beispiel: Wenn ich eine Zeitangabe als Teil der Entropie verwende, was glaubst du dann, wie relevant Jahr, Monat, Tag, Stunde oder gar Minute sind?
Du meinst, dass die Entropie zu gering ist. Gutes Beispiel übrigens.
Ist ähnlich wie mit dem Hashen von Telefonnummern, wie es Messenger (der Typ Messenger, der deine Kontakte hochläd und dann einen auf Datenschutz machen will) betreiben, um dann sagen zu können „Wir können ihre Nummer garantiert nicht wiederherstellen!“.
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)
-
-
Hello,
Wenn ich den Token versuche zu knacken, fällt mir das doch nicht leicht, wenn der Zufallszahlengenerator Zahlen mit hoher Entropie erzeugt und der Token lang genug ist, weil ich den ja zu erraten versuche!
Den Raum für die möglichen Tokens teilen sich aber alle deine 300.000 Besucher. Die sind zwar nicht alle zur selben Zeit aktiv, aber 30.000 mögliche Treffer sind auch schon ganz nett für jemanden, der nur irgendwo Unsinn treiben will.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
-
-
-
-
Hallo TS,
Vorsichtig sollte man aber auch damit sein, nicht zu viele Login-Versuche zuzulassen und dies für Benutzeraccounts und IPs (nur auf IPs ist eine schlechte Idee, die Nutzern eines Uni- oder Schul-Netzwerks würden sich sehr darüber freuen 😟) auf eine bestimmte Anzahl von Versuchen zu beschränken.
Abgewiesene Logins sind nicht das Thema, sondern Session-Klau mittels erratener Session-Tokens. Also in PHP gesprochen, einfach nur PHPSESSID senden, was das Teug hält, bis eine passt.
Das habe ich verstanden, wollte nur noch mal allgemein auf betonen, dass IP-Blocken nicht die beste Wahl ist. Aber du hast recht, normale Nutzer senden nicht einfach wild irgendwelche Session-Keys, das hatte ich tatsächlich nicht auf dem Schirm. Aber die Frage ist dennoch, was machen die anderen Nutzer, die am WLAN-Hotspot, Uni-Netzwerk oder sonstwo hocken, wenn sie sich zufällig die IP mit einem Cracker teilen?
Derartige Requestbursts sind bisher nicht abgefangen.
Müsste das nicht eigentlich PHP selbst machen (müssen), weil das ja für die Verwaltung der Sessions zuständig.
Gruß
Julius--
„Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
– Andrew S. Tanenbaum (Quelle)
-
-
-
-
-
-
Hello,
Das erinnert mich an eine Aufgabe, die ich seit langem auf dem Zettel habe.
Wie kann ich auf dem Server feststellen, dass Session-Tokens "durchgetickert" werden? Ist bei PHP und dem inzwischen erheblich erhöhten Wertebeeich von Session-Tokens unwahrscheinlich, dass jemand trifft, aber es ist nicht unmöglich!
Ich habe gerade noch etwas gefunden, was ich mir morgen näher angucken werde:
mod_evasive
ist aber bei Apache nicht in der Liste der Module...
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-
-
-
Hello,
Security by Obscurity bezeichnet ein Vorgehen, bei dem man sich darauf verlässt, dass ein potentieller Angreifer einen Zugriff nicht erlangt, weil er nicht genau weiß, wie das System aufgebaut ist: etwa habe ich eine URL, die es erlaubt etwas zu löschen, aber sie ist nur dem Admin bekannt. Die Annahme, dass niemand diesen Link kennt und es deshalb sicher ist, ist Security by Obscurity. Die Praxis hat gezeigt, dass diese Annahme prinzipiell nicht als gegeben anzunehmen ist. Dieses Konzept funktioniert nicht. Stattdessen geht man davon aus, dass der Angreifer potentiell jedes Detail des Systems kennt. Diese Annahme führt zu einer paranoideren Denkweise und deshalb dazu, dass man Zugriffsrechte genauer prüft, Zugriffe schützt und ähnliches.
Das zeigt uns auf jeden Fall, dass bei HTTP Obscurity und Confidentiality nicht weit auseinander liegen. Egal, ob dort Tokens oder Credentials übertragen werden, sind sie spätestens bei Benutzung streng genommen nicht mehr als geheim anzusehen. Das technische System muss also auch in der Lage sein, das Secret zu bewahren.
Liebe Grüße
Tom S.--
Die Krawatte ist das Kopftuch des Westens
-