Diskussion:Security through obscurity

IP-Adresse

was ist an IP-A. verbergen böse? bitte ausführen. --'~' 12:50, 11. Sep 2003 (CEST)

Nichts ist daran böse, es ist nur eine Form "Sicherheit durch Geheimhaltung". Die gennanten Beispiele sollten eigentlich alle wertfrei sein (sofern man sie nicht technisch rechtfertigen kann). Wo interpretierst du, dass es "böse" ist? --diddi 13:08, 11. Sep 2003 (CEST)

Beispiele

die vielen beispiele verwirren mehr, als dass sie helfen. sie setzen erhebliches fachwissen voraus, währenddem das konzept von security through obscurity eigentlich einfach ist. ich hab mal das beispiel aus der en-wikipedia übersetzt. der beitrag dort gefällt mir (in seiner einfachheit) um einiges besser. aber ich kann nicht abschätzen, ob die deutschen beispiele wirklich neue infos enthalten. ansonsten würde ich sie gleich löschen ;-) --Diftong 17:50, 11. Sep 2003 (CEST)

Man kann die Beispiele insofern vereinfachen, als dass man die techn. Details einfach weglässt. Das hat wie gesagt den Vorteil, dass sie "einfacher" sind, aber sie sind dann leider auch unbegründet. Ich weiß leider nicht genau, wie man hier einen solchen Spagat zwischen Einfachheit und Details schafft. Tipps sind natürlich willkommen. Die englische Seite konzentriert sich mehr auf allgemeine Sicherheit, deshalb sind wohl dort keine Bsp. aus der Netzwerksicherheit zu finden.

Es steht dir natürlich frei die Definition hier auszuweiten und allgemeine, einfache Beispiele einzuarbeiten. --diddi 18:47, 11. Sep 2003 (CEST)

Schönes Beispiel wäre doch auch WLAN. Deaktiviert man die SSD-Ausgabe, findet keiner "so schnell" das WLAN ... schützt aber ansich nicht mehr oder weniger vor einem Angriff. (nicht signierter Beitrag von 93.222.146.170 (Diskussion) 20:00, 8. Feb. 2013 (CET))

Passwörter

Aus dem Artikel:

Passwörter: Das sehr weit verbreitete Konzept von Passwörtern ist auf den ersten Blick auch security through obscurity: Man hält ein Passwort geheim, um sicher zu gehen, dass nur Befugte Zugang oder Zugriff auf Etwas haben.

Dieses Konzept besteht aus den zwei Teilen Passwort und (Passwort-)Eingabemaske, die einander bedingen. Wenn man nicht annähme, dass man beide Komponenten tatsächlich geheimhalten könnte, wäre das Passwort-Konzept ad absurdum geführt. Man spricht deshalb nur dann von security through obscurity, wenn versucht wird, beide Komponenten geheimzuhalten.

Was ist mit dem zweiten Blick? Und sind nicht normalerweise nur die Passwörter geheim, während die Eingabemaske öffentlich zugänglich ist? Ich habe dieses Beispiel irgendwie nicht verstanden. --HoHun 17:04, 2. Nov 2004 (CET)

Beispiel

Wenn zum Beispiel jemand den Schlüssel seiner Haustüre in einem Blumentopf versteckt, für den Fall, dass er sich aus dem Haus ausschließt, verlässt er sich auf Security through obscurity. Ich bin mir nicht sicher, ob das Beispiel günstig ist. Ein Laie könnte annehmen, dass Security through Obscurity heisst, dass das dahinterliegende System unsicher ist. Dies ist jedoch nicht zwangsläufig so, auch ein gut durchdachtes komplettes Sicherheitssystem, kann als zusätzliche Komponente StO anwenden. Also Verschlüsselungsverfahren deren Quellcode versteckt wird, sind dadurch nicht zwangsläufig unsicherer, nur wissen wir als Aussenstehende (ohne eine NDA zu unteerschreiben) oft nicht, welche Sicherheit uns das System nun tatsächlich bietet. -- Dishayloo [ +] 20:57, 7. Feb 2005 (CET)

Überarbeitung (erl.)

Begründung für Überarbeitungsbaustein: Das Beispiel mit dem Schlüssel im Blumentopf ist nett, aber man könnte noch eine ganze Menge aus dem englischen Artikel übernehmen, der schon wesentlich umfangreicher ist. -- Gebu 13:32, 24. Mai 2005 (CEST)

Ich finde das Beispiel mit dem Blumentopf überhaupt nicht nett, denn 'Schlüssel im Blumentopf' ist alles andere als obskur - es ist oft geübte Praxis, und daher fast das Gegenteil von SbO.--84.59.80.9 9:25 17. Dez. 2005 (CEST) Signatur geändert gemäß Diff. Edit nicht von mir. --Stefan »Στέφανος« ⸘…‽ 00:01, 10. Feb. 2017 (CET)

Können wir den Baustein mal entfernen? Er sollte doch eher bei faktischer Unlogik seiner Aussage da stehen, aber nicht, weil so eine Formulierung nicht ungeteilte Zustimmung findet... das ist auch 2005 gepostet worden und ohne weiteren Kommentar geblieben... (also mache ich das jetzt..) denkt --Jabo 03:03, 19. Nov. 2007 (CET)

Dieser Abschnitt kann archiviert werden. Gebu (Diskussion) 09:02, 2. Jan. 2021 (CET)

schwer/nicht verständlich

ich kenne den Konzept "Security through obscurity" nicht und für mich ist der Artikel nicht wirklich verständlich! Ist "Security through obscurity" ein mögliches Sicherheitskonzept oder ein naives Sicherheitsvertrauen? Hat "Security through obscurity" prinzipiell eine negative Konotation? ? 3:33, 11. Jan 2006 (nicht signierter Beitrag von 141.70.115.203 (Diskussion) )

Anderes Beispiel

"SESAM ÖFFNE DICH" ist nicht gerade ein Kracher wenn's um sichere Kennwörter geht, aber man müsste doch einen der vierzig Räuber foltern, um zu erfahren, wo in dem Gebirge und an welcher Felswand jetzt das versteckte Tor liegt.

Für mich ist security through obsurity kein Konzept, sondern ein Element oder eine Vorgehensweise mit verschiedenen positiven und negativen Eigenschaften. In einigen Fällen ein MUSS (Firewall, VPN, W-LAN, ...), manchmal einfach nur praktisch und auf die Schnelle (Versteckter Link auf der Website, auf öffentlichen http servern Dateien in Unterverzeichnissen ablegen) aber oft auch störend, wenn man ein Netzwerk verwalten muss und sich jedesmal überlegen muss hinter welcher IP Adresse und an welchem Port man an die Printserverkonfiguration kam. Ich SEHE ganz gerne meine Rechner im Netzwerk, inhouse sollten dann doch Passwörter genügen.

Es erhöht "relativ" die Sicherheit indem es: 1. Ein erkennen von Informationen mit Standardwerkzeugen (Browsern (Datenbank, Datei, HTTP, ...)) verhindert. 2. Auch bei aggressiveren Attacken dafür sorgt, dass sich zu sichernde Systeme Stumm verhalten.

Kurzdefinition etwa: Du siehst es nicht, und es antwortet auch nicht, solange du nicht genau weist WO du welche FRAGE stellen musst, damit du mit dem System kommunizieren kannst.

Es erhöht aber auch den Administrationsaufwand. Früher oder später hält man sich schlicht nicht mehr an Standards, und wenn man das Ganze dann auch nicht dokumentiert (sonst wärs ja nicht obskur) darf man dann nicht mehr in Urlaub fahren :)

(nicht signierter Beitrag von Gernegut (Diskussion | Beiträge) 15:24, 1. Mai 2006 (CEST))

Das Beispiel mit den Portscans ist ungünstig

"Konfiguration einer Personal Firewall so, dass Anfragen auf Ports ignoriert (DENY) anstatt negativ beantwortet werden (REJECT) und hoffen so, unsichtbar und sicherer zu sein."

Diese Hoffnung ist falsch bzw. beruht auf Unkenntnis von ICMP. "Keine Antwort" bedeutet in IP-Netzen immer "da ist was, das Pakete verschluckt". Von "unsichtbar" kann da keine Rede sein. Die meisten guten Portscanner erkennen das auch so.

Um unsichtbar zu sein, müßte vom Knoten _vor_ dem Zielrechner ein "ICMP Destination Unreachable" kommen. Dazu müßten Dialup-User allerdings meistens in die Router-Konfiguration ihres Internet-Providers eingreifen.

(nicht signierter Beitrag von 195.140.35.35 (Diskussion) 10:28, 15. Mai 2006 (CEST))

nicht nur auf die IT beschränkt!

Security by Obscurity wird auch z.B. bei Geldautomaten (wer ausser der Hersteller kennt schon die Software genau da drin?) oder bei der Atomenergie (wer ausser den Mitarbeiter kennt die Sicherheitsmaßnahmen und Lücken in einem KKW genau?) angewendet, auch bei der FIFA WM 2006 wurde Security by Obscurity angewendet, da man erst im nachhinein bekanngab dass nur 10% der Tickets beim Stdioneinlass auf ihren wahren Inhaber überprüft wurden!! --Spazion 09:26, 15. Aug 2006 (CEST)

Ursachen der Geheimhaltung

Aus dem Artikel:

Immer wieder werden Verschlüsselungsalgorithmen jedoch auch geheimgehalten. Dies kann zwei Ursachen haben:

[…]

b) Durch die Kenntnis vom verwendeten Verschlüsselungsalgorithmus könnten eventuelle Schwachstellen entdeckt werden, sodass sich erst bedeutend später herausstellt, dass die Verschlüsselung nicht effektiv ist. RC4 ist ein Beispiel dafür. Der Algorithmus ist die Basis der WEP-Verschlüsselung heute weit verbreiteter WLANs. Auf diese Weise führt security by obscurity zu einem Verlust von Sicherheit, da wegen security by obscurity die vermeintlichen Sicherheits-Methoden nicht auf ihre Wirksamkeit überprüft, die unwirksamen Methoden nicht frühzeitig als solche verworfen werden.

Das ergibt für mich nicht richtig Sinn. Der Anfangssatz suggeriert, dass es im Folgenden um die Motivation für Security through Obscurity geht, am Ende von Punkt b wird dann aber von einer negativen Folge von Security through Obscurity gesprochen. Diese negative Folge ist ja wohl kaum eine Motivation dafür, Security through Obscurity zu verwenden.

-- Blauwal 20:37, 2. Nov. 2006 (CET)

Irreführender Artikel - löschen?

Sicherheit durch Unklarheit wird doch erst dann ad absurdum geführt, wenn es zur Monokultur wird. Sprich an jeder sich bietenden Stelle benutzt wird. Das Problem dieses Artikels ist die eingeschränkte Sichtweise. Interessant, da dies die einzig logische Erklärung zu diesem Artikel wäre, ist die Entstehungsgeschichte dieses Spruches und dessen nachträgliche Verwendung durch diverse Kultgruppen.

Die Erklärung der Popularität dieses Spruches leitet sich doch nur durch die Open Source Gemeinde ab. Allen voran die (salopp formuliert) Linuxfanatiker. Denn diese "Gemeinde" will "uns" weiß machen, das Sicherheit nur und ausschließlich mit Open Source Sicherheit gewährleistet ist.

Vom Grundgedanken her korrekt und einzig logische Schlußfolgerung. Problematisch wird es aber auch hier mit dem Thema Monokultur. Etwas das zig Tausendfach den selben Namen hat und nicht Personifiziert ist, wird früher oder später über seine eigenen Beine stolpern müssen. Denn werden Fehler durch "böses Personal" gefunden, wird jedes weit verbreitete Ding, einem Angriff zum Opfer fallen, da sich der anzugreifende Punkt immer an der selben Stelle befinden wird oder den selben Namen hat. Und als Beispiel kann hier durchaus ein Gitter vor dem Fenster herhalten. Ich muss das Fenster nicht schließen, um Sicherheit gewährleisten zu können. (Wobei Vergleiche immer hinken werden!)

Andererseits, und hier ist ein weiteres Problem, viele sind der Meinung Sicherheit alleinig mit Unsicherheit zu verwechseln. Sprich schlechte Dinge durch solche Maßnahmen zu "verbessern" (oder sicherer zu machen), was letztendlich natürlich ein Trugschluß ist.

Leider kann man in vielen Fällen aber diverse Dinge nicht "personifizieren", also "einmalig" machen, da damit ein erheblicher Mehraufwand besteht. Als Beispiel seien hier Firmennetzwerke genannt, die nur damit funktionieren können. Womit dieser Artikel einzig und allein seine Daseinsberechtigung hätte.

Denn, ersetzt man Sicherheit durch Unsicherheit gegen Sicherheit durch Persönlichkeit, dürfte der Artikel wesentlich einfach werden. Jedoch gibt es diesen Sprachgebrauch nicht.

Daher, dieser Artikel ist in der aktuellen Form irreführend und von der Grundsatzaussage her selbst als "wertend" zu betrachten. Er deckt nur einen kleinen Teil der gesamten Diskussion zu diesem Thema ab, dass sich in vielen Diskussionsforen schon über Jahre hinzieht und äußerst kontrovers geführt wird.

Ich plädiere auf Artikel löschen. Es sei denn es werden BEIDE Seiten zu dieser Diskussion vernünftig mit ihren Argumenten dargestellt. Bisher erkenne ich nur eine sehr einseitige und beschränkte Sichtweise.

(nicht signierter Beitrag von Oberwaldforsthorst (Diskussion | Beiträge) 09:35, 8. Jan. 2007 (CET))

Ich habe leider nicht ganz verstanden, worauf du hinaus möchtest. Sicherlich kann der eine oder andere Aspekt hinzugefügt werden, aber das ist bei fast jedem Artikel hier so. Deshalb kann man die nicht einfach alle löschen. Das der Begriff vorwiegend von der Open-Source-Gemeinde geprägt ist, ist meiner Meinung nach, kein Problem. Der Begriff Heidentum ist beispielsweise vorwiegend durch Christen geprägt. Dadurch verliert er ja nicht seine Berechtigung hier auf zu tauchen. --Nico Düsing (Diskussion) 14:24, 8. Jan. 2007 (CET)

Das Problem was ich mit diesem Artikel habe, ist die fast schon militante Ausführung des geschriebenen. Ich persönlich habe ein Problem mit dem alleinigen Anspruch, das "Sicherheit durch Unklarheit", ein falscher Weg sein soll, der mit diesem Artikel jedoch impliziert wird. Denn in den genannten "Kreisen" (Forendiskussionen) wird in fanatischer, ja fast schon Sektenartiger Weise, "Security through obscurity" als das Böse dargestellt. Denn ich finde im aktuellen Text keine Stelle, die auch Vorzüge vermittelt, die nachweislich vorhanden sind.

Ich möchte hier lediglich darauf verweisen, das dieses Thema Monokultur nach sich zieht, wodurch es angreifbarer wird. So zumindest interpretiere ich die hier angeführten Beispiele. Zumal sich diese Diskussion auf einen Artikel aus dem Jahr 1949 bezieht, der meines Erachtens nach zum Teil überholt ist.

Ich könnte den Artikel zwar selbst verändern, bin mir aber nicht sicher ob damit allen genüge getan wird. Eigenen Umfragen zufolge sind eben rund 60% nicht meiner Meinung ;o) Deshalb auch meine Zurückhaltung.

(nicht signierter Beitrag von Oberwaldforsthorst (Diskussion | Beiträge) 16:50, 10. Jan. 2007 (CET))

Aber es ist doch in bestimmten Bereichen auch ‚böse‘. Es ist nun mal so, dass vor allem in der Computerwelt, problemlos sehr viele Angriffe in sehr kurzer Zeit ausprobiert werden können. Dadurch hält die Geheimhaltung nicht immer lange. Wenn erstmal ein möglicher Angriff erkannt ist kann man den auch nutzen (siehe Beispiel mit dem Haustürschlüssel). Besser wäre es, man hätte einen Schutz, der gar keine Angriffe ermöglicht.

In anderen Bereichen ist es wiederum Sinnvoll. Beispielsweise sollten Firmen ihre Rezepturen von z.B. Lebensmitteln geheim halten. Hier ist es auch schwer durch Ausprobieren die Rezeptur heraus zu finden (schlechtes Beispiel, da es nichts mit Computern zu tun hat). Als zusätzliche Sicherheit kann Security through obscurity natürlich auch hilfreich sein.

Was das Alter des Artikels angeht, weiß ich nicht welchen du meinst. Die einzige Jahreszahl auf dem Artikel vom Link ist 2000. --Nico Düsing (Diskussion) 10:00, 11. Jan. 2007 (CET)

Das Jahr bezieht sich auf den hier; Claude_Shannon#Biographie (8. Absatz), wo diese Theorie das erste mal veröffentlicht worden ist.

Ich mache mir mal Gedanken zu dem Artikel, hier in der Wikipedia. Vielleicht schreib ich den doch mal um. ;o) --OwaFoHo 12:21, 12. Jan. 2007 (CET)

Vielleicht sollte man darauf hinweisen, dass zwar SbO die Sicherheit erhöht, da ein potentieller Angreifer erst noch das zu Grunde legende System verstehen muss, aber andererseits auch die Anzahl derjenigen deutlich veringert, die Fehler finden können. Das wäre eine neutrale Darstellung. Meiner persönlichen Meinung nach, hat die Vergangenheit einfach gezeigt, dass es wichtiger ist, viele Kontrollinstanzen zu haben, auch wenn damit ein kleiner Teil der potentiell möglichen Sicherheit verloren geht.

(nicht signierter Beitrag von Subiks (Diskussion | Beiträge) 17:37, 19. Apr. 2007 (CEST))

Der Artikel beschriebt aber, was damit gemeint ist und führt den damit verbundenen Flamewar hoffentlich nicht fort. Insofern ist es besser, ihn neutral zu gestalten, als ihn mit Vorwürfen aus diesem Flamewar zu disqualifizieren. Der Artikel beschreibt ein Phänomen, das so real ist, daß es einen verbreiteten und damit eben (er)klärungsbedürftigen Namen hat. Eine Löschng ist also auf jeden Fall schlechter als (konstruktiv) zur Beschreibung beizutragen, denke ich. --Jabo 02:33, 19. Nov. 2007 (CET)

NPOV

im artikel/abschnitt wird suggeriert, dass open-source software prinzipiell sicherer ist, als closed-source software - dies schiesst am thema des artikels vorbei

zudem gibt es dafür nicht wirklich belegte quellen - die windows-schiene mag viele sicherheitslücken haben, aber es gibt auch genug auf der gnu/linux schiene (unix lass ich jetzt mal offen vor) - klar sind die anzahl der attacken auf privatrechner mehr auf windows gerichtet, das liegt aber nicht an closed/open-source oder der verschleierung des quellcodes oder sonstetwas sondern schlichtweg am verbreitungsgrad - bei webserver siehts schon wieder anders aus - aber es ist nun mal ein dogma, dass closed source "sicherer" ist als open source, wenn ma es NUR aus der sicht von sicherheit durch verschleierung sieht

im artikel fließen aber alle möglichen anderen faktoren wieder in die bewertung ein

wenn ich einen safe aus pappe baue und einen extrem komplexen verschlussmechanismus verwende, dessen funktionsweise niemand kennt, ist der mechanismus prinzipiell sicher als ein stahlschrank, der mit einer unversperrten türklinkte "gesichert" ist, deren funktionsweise jeder kennt - dass der papp-safe aus anderen gründen unsicherer ist, steht aber hier nicht zur debatte --suit 16:22, 21. Jul. 2007 (CEST)

Über Open Source oder nicht, darüber kann man sich sicherlich streiten, aber das es keine Quellen gibt, die sagen das Kryptografie mit Open Source besser ist, stimmt sicher nicht!

Zitat von F. L. Bauer bedeutenden deutschen Krytologen aus seinenem Buch „Entzifferte Geheimnisse“ 3. Auflage S. 234:

„Offener Quell-Code ist dabei ein wesentliches Erfordernis, denn jedes Kryptosystem mit einem unpulizierten Algorithmus kann unerfreuliche Überraschungen in sich bergen.“

Gruß Azrael. 03:01, 6. Sep. 2007 (CEST)

wie gesagt, das hat nichts mit open source oder closed source zu tun, der algo von rot-13 ist quelloffen, aber ist er deshalb sicherer als nagravision? --suit 21:56, 8. Sep. 2007 (CEST)

Du hast "notwendiges" mit "hinreichendes" Kriterium verwechselt. Quelloffenheit bzw. offengelegte Algorithmen sehen viele als notwendiges Kriterium für sichere Kryptoverfahren an, hinreichend ist das natürlich noch lange nicht. --RokerHRO 21:49, 9. Sep. 2007 (CEST)

stimmt, mein fehler - wenn man aber alle notwenigen anforderungen außen vor lässt und nur die blanke tatsache open vs closed source nimmt, ist closed source prinzipiell sicherer

nochmal das beispiel rot13, lassen wir die tatsache des kennens eines algorithmus auch noch weg - wenn jemand einen rot13-text sieht, kann er ihn mit kenntnis des quelloffennen algoritmus leicht entschlüsseln = nahezu null aufwand, ohne kenntnis der dahinterliegenden logik wirds länger dauern (gut, rot13 ist sehr einfach, aber das ist nicht der punkt) --suit 19:31, 27. Sep. 2007 (CEST)

Siehe meinen Beitrag im obigen Abschnitt.. es kann doch nicht Job der Wikipedia sein, ein Thema auszuklammern, weil es kontrovers ist. Lieber soll beschrieben werden, warum es das ist. Meiner Meinung nach leistet der Artikel das, weil er die Gegenüberstellung unterschiedlicher Ideen beinhaltet. Daß er diese eine beschriebt, weil sie einen Namen hat, den er zu erklären versucht, ist für mich sein Sinn. --Jabo 02:44, 19. Nov. 2007 (CET)

Das Beispiel ROT13 ist eigentlich sogar perfekt, denn durch Offenlegen des Quellcodes könnte man sofort sehen, dass das Verfahren unsicher ist und daher lieber ein anderes, tatsächlich sicheres, Verfahren genutzt werden sollte (denn DAS erhöht letztlich die Sicherheit). Denn ein wesentliches Problem von Security through Obscurity, das seltsamerweise nicht im Artikel genannt wird ist, dass kein Geheimnis dauerhaft eins bleibt (also auch nicht der Algorithmus). Umso weniger, je mehr Leute es kennen. Und wenn man nun ROT13 als Beispiel heranzieht, dann müsste man ja, um das System im Krieg zu verwenden, mindestens jedem Kommandanten das Verfahren mitteilen. Und da das Verfahren, im Gegensatz zu den Schlüsseln, nicht beliebig änderbar ist, ist klar, dass das irgendwann in falschen Händen landen muss. Wäre das Verfahren an sich aber sicher (dazu braucht es nicht quelloffen zu sein, Quelloffenheit erhöht lediglich die Chance, früh/rechtzeitig von der Unsicherheit Kenntnis zu erlangen), dann käme es allein auf den Schlüssel an, und da jeder Kommandant einen eigenen Schlüssel bekommen hätte, wäre im Ernstfall der Schaden deutlich geringer. Wenn aber bei Kenntnis des Verfahrens der Schlüssel zur Nebensache wird, hat man nur so lange echte Sicherheit, wie man das Verfahren und den Schlüssel gleich behandelt - also niemandem zugänglich macht, wodurch der Einsatz des Verfahrens auf extrem kleine Personengruppen beschränkt bleiben muss. Das macht so ein Verfahren für die meisten Anwendungsfälle wertlos - und auch das muss man rechtzeitig wissen! Auch darf man nicht vergessen, dass gerade bei Programmcode durch Reverse-Engineering Dinge erkannt werden können, die man geheim zu halten glaubte. Da kann man auch mit dem Ausschluss von Kellerhackern nichts ausrichten, denn der eigentliche Gegner sind Kriminelle (gegnerische Geheimdienste gehören auch dazu), und die haben erstens keine Probleme mit irgendwelchen Gesetzen und zweitens riesige Budgets für genau sowas. Und dann sind, im Falle von Software, die Folgen für die Anwender ggfs. sehr viel gravierender, als wenn irgendein Hobbyhacker das veröffentlicht. Außerdem kommt bei Software noch hinzu, dass nicht nur der Algorithmus selber geprüft werden können sollte, sondern auch seine Implementierung. Es gibt immer wieder Fälle, wo ein eigentlich sicherer Algorithmus durch irgendeinen Fehler bei dessen Implementierung zumindest erheblich geschwächt wurde. Das betrifft dann nicht nur die Anwender der bestimmten Software, sondern auch die, die mit diesen über das Verfahren kommunizieren. Natürlich hilft die quelloffenste Software nicht, wenn sich niemand die Mühe macht, den Quelltext zu analysieren, und es können auch dann Fehler übersehen werden. Die Chancen dafür werden halt lediglich reduziert bzw. die Zeiten verkürzt. Genauso kann es natürlich auch vorkommen, dass ein nicht quelloffener Code oder Algorithmus tatsächlich sicher ist. Man weiß es dann eben einfach nicht, und erfährt es ggfs. erst wesentlich später, dass es nicht (mehr) so ist. Man könnte also sagen, dass die Abwägung ist: möchte ich meinen Algorithmus mit aller Welt teilen, um mit erhöhter Wahrscheinlichkeit vor dem großflächigen Einsatz zumindest gewarnt zu sein? Oder möchte ich durch Geheimhaltung von Verfahren und Implementierung versuchen, die (unweigerliche) Entdeckung von Schwachstellen möglichst lange hinauszuzögern und dabei riskieren, selbst nicht rechtzeitig von den Schwachstellen zu erfahren, die andere evtl. längst entdeckt haben? "Schwachstellen" bezieht sich auch auf Fortschritte in der Technik, die Brute-Force-Angriffe sinnvoll möglich machen, egal, ob der Algorithmus selber wirklich sicher ist oder nicht.87.123.40.20 03:08, 29. Apr. 2021 (CEST)

Falscher Satz

Folgender Satz ist, so wie er jetzt dasteht, falsch oder zumindest äußerst irreführend:

Sicherheit, die ausschließlich auf der Geheimhaltung von Informationen beruht, hat sich oft als ungenügend herausgestellt.

Natürlich muss man gewisse Informationen geheimhalten, etwa Kennwörter, Schlüssel usw., sonst gäbe es keine Sicherheit. Entweder, jemand findet da eine bessere Formulierung oder ich streiche den Satz ersatzlos. :-/ --RokerHRO 23:22, 4. Aug. 2007 (CEST)

Da steht aber ausschließlich ... das ist doch die passende Formulierung? Es wird doch beschrieben, daß man zwar Schlüssel etc. geheim halten muß, aber nicht (immer) die Logik? Es wird also doch in der Aussage des Artikels ein Unterschied gemacht zwischen Informationen, die geheim bleiben müssen und der Methode, mit der das geschieht?

Ein starker Algorithmus wie z. B. der Advanced Encryption Standard erfordert aus der Sicht der reinen Kryptographie-Sicherheit keine Geheimhaltung des Verfahrens, sondern nur des Schlüssels.

etc. .... --Jabo 01:50, 19. Nov. 2007 (CET)

übersetzung des zitates

auch mittels dict.leo.org verstehe ich nicht so richtig den sinn des zitates Given enough eyeballs, all bugs are shallow. es wäre schön, wenn jemand, der der englischen sprache mächtig ist, die deutsche bedeutung in klammern hinter das englische zitat packen würde. Loth 13:43, 27. Sep. 2007 (CEST)

Vielleicht so: "Mit genügend Augen werden alle Bugs auffindbar" --RokerHRO 15:04, 27. Sep. 2007 (CEST)

shallow heißt ja u.a. "oberflächlich"... d.h. ergründbar. Gemeint ist "Bei vielseitiger Prüfung (=enough eyballs) sind/werden alle Programmfehler sichtbar(er)"... Es ist immer heikel, Redewendungen einer Sprache so zu übersetzen, daß man zwar in der Nähe der Formulierung bleibt, aber auch wirklich die Aussage übersetzt.

Was gemeint ist, ist in der Hinsicht ein klassisches Argument für OpenSource: Wenn alle hin gucken können, kann niemand was Obskures verstecken. Auch simple Fehler fallen schneller auf. Ohne Bewertung dieser Aussage (die ich persönlich aber stütze) ist das ihre Bedeutung. Die Übersetzung von RokerHRO trnasportiert das, hört sich aber auch "holperig" an....

"Wenn genügend Leute hin schauen, werden Fehler (leichter) gefunden."

Das wäre mein Vorschlag... --Jabo 02:05, 19. Nov. 2007 (CET)

Wie wäre es mit "Mit genügend vielen Augen werden alle Programmfehler sichtbar" oder noch kürzer: "Genügend Augen sehen alle Programmfehler" -- 10:10, 27. März 2008

Überarbeitung

Ich wollte die Überarbeitungsbemerkung löschen, aber was war gemeint?

Früher war eine vorgeschlagen, was ich nicht mehr hinreichend finde, aber war es diese? --Jabo 03:27, 19. Nov. 2007 (CET)

Überarbeitung der Beispiele

Teilweise sind die Beispiele irreführend. Manche Maßnahmen die hier als Beispiel für Security through obscurity angeführt werden haben andere Gründe.

Portscans „ignorieren“

Es geht hier um Anfragen auf unbenutzte!!! Ports. Oft soll die Firewall diese Pakete verwerfen (DENY/DROP) statt zu beantworten (REJECT), da dies ressourcenfreundlicher ist.

Nein ist es nicht. Verwirft die FW die Pakete kommentarlos, wird der Sender sie bis zum Timeout wiederholen. Wüßte er aus der Antwort, daß kein Dienst läuft, würde er das lassen. Verwerfen erhöht also den Traffik. Jabo 09:25, 8. Feb. 2008 (CET)

Dienste (Ports) verstecken

Wenn der Dienst auf einen anderen Port läuft, so schafft das eine Hürde für "dumme" Bots. Auch ein gutes Portscanner findet den anderen Port eben NICHT leicht. Es besteht die gute Chance den Portscan als solchen zu erkennen und zu blockieren.

Portscanner können nicht nur schauen, welcher Port auf ist, sondern auch, welcher Dienst tatsächlich läuft. Die das nicht können, bezeichnest du selber als "dumme Bots". Ergo: Du bestätigst das Argument damit und mit der Bemerkung, daß man (durch dann zusätzlichen Aufwand!) den Scan als solchen erkennen muß, daß es sich um eine wirkungslose Maßnahme handelt, einfach nur den Port zu ändern. Genau deshalb ist es (unsinnige) "Security through obscurity", sowas zu tun. Jabo 09:25, 8. Feb. 2008 (CET)

Räusper, ein Portscanner ist nur ein Portscanner. Das was Du meinst ist eine Anwendung, die auf einem Portscanner basiert. Dienste zu verstecken, Ports umzubiegen das Vorhanden sein bestimmter Dienste zu verschleiern ist genau ein Beispiel zu Security by Obscurity. Ob es sinnig ist, sollte nicht Thema der Erklärung des Begriffs sein.--Amazing 09:35, 23. Mär. 2008 (CET)

Ping „ignorieren“

Das Ignorieren von ICMP Echo Request ist bei anfälligen Systemen eine geeignete Maßnahme gegen den Ping of Death. Das Beispiel mit der Telefonnummer ist unpassend, da die Signalisierung hier von der lokalen Vermittlung und nicht von Angerufenen kommt. Außerdem tritt der Fall nie ein.

Doch, ist vergleichbar. Wenn das Routing zum Zielhost eines Pings nicht möglich ist, antwortet eben nicht der Host (der wurde ja nicht erreicht), ebenso wie bei falscher Nummer nicht das nicht vorhandene Telefon antwortet. Wird also das Paket an einen Host geleitiet, der als vorhanden bekannt ist, der antwortet dann aber nicht, ist der Rückschluß möglich, daß der Rechner eben da und nicht weg ist. Sonst käme eine andere Antwort (bzw. überhaupt eine!) von er "Vermittlung".

Ich verstehe auch nicht, welcher Fall nie eintritt?

Muß nicht außerdem das Ignorieren von ICMP Echo Request in irgend einer Instanz, die an sich ja im Netz ist, "beschlossen" werden? Man schließt also nicht den Datenverkehr aus, sondern nur die Hälfte davon sozusagen, nämlich die eigene Antwort. Ein POD-Angriff liegt also unvermindert mit voller Last auf der Leitung.

Dein Einwand steht übrigens ohne Signatur hier... Jabo 09:25, 8. Feb. 2008 (CET)

(nicht signierter Beitrag von 79.206.222.135 (Diskussion) 04:42, 31. Dez. 2007 (CET))

Füllwörter

Moin,

habe mal eine Handvoll von diesen nervigen Füllwörtern entfernt. Jemand mit Ahnung vom Thema kann ja mal die Sätze verkürzen und auf den Punkt kommen. Teilweise ist es ja wirklich schwer verständlich – aber nur aufgrund der Bandwurmsätze.

--89.182.150.255 00:37, 9. Feb. 2008 (CET)

Baustein

hallo,

ich möchte gerne beide Bausteine zu den Belegen und den Beispielen entfernen, weil ich glaube, daß das Thema hinreichend von mehreren Seiten beleuchtet ist und das Vorhandensein der Bausteine eher wie ein Teil des Flamewars aussieht, den das Thema sicherlich provoziert.

Aber sich daran zu beteiligen, ist doch wirklich irrelevant, oder?

(nicht signierter Beitrag von Jabo (Diskussion | Beiträge) 02:47, 9. Mär. 2008 (CET))

Wer im Glashaus sitzt....

Hallo!

Ich habe es geschafft, einige Beiträge zu lesen, ohne dabei in Verärgerung zu geraten.

Der Beitrag Security by Obscurity ist weder ein Schlagwort irgendwelcher Linuxfreaks, noch sollte er in irgendeiner Weise als Rechtfertigung für persönliches Sendungsbewusstsein und damit für ein Wiki irrelevante Meinungsbilder dienen.

Jedem steht es Frei sein eigenes Wiki zu bauen.

Der Artikel selbst ist -- ob es EINEM gefällt oder nicht -- Teil unserer Realität bzw. wird heute immer noch angewendet.
Über dessen sinnhaften Inhalt kann man urteilen, wie immer man mag, jedoch hat dies keinen erklärenden Charakter.

Das was hier z.T. abläuft, entzieht sich jeder vernünftigen Betrachtung!

Ich bitte darum, das sämtliche Flame-Kommentare im Text und angebliche fehlende Quellenangaben (welche zur Erklärung der "Floskel" nicht nötig sind!) zu entfernen.

Hier spielen sich einige "Autoren" als Wikipolizei auf, ohne wirklich selbst über das wichtigste Werkzeug der Selbstreflektion zu verfügen. Dies findet man auch bei Heranwachsenden bzw. bei Greisen.

Ich habe den Artikel nun überarbeitet und als Ergänzung zum Wort "Geheimhaltung", welches bereits zu Kontroversen führte, das Wort "Verschleierung" hinzugefügt, auch weil es IMHO dem englischen "obscure" (Unklar/Merkwürdig) näher kommt.

Wichtige Passagen habe ich nur auskommentiert. Wirklich Unwichtiges habe ich Entfernt (Siehe Versionen).

Mfg! Andreas --Amazing 19:53, 23. Mär. 2008 (CET)

"Jedem steht es Frei sein eigenes Wiki zu bauen." - klingt als ware das hier deines. (nicht signierter Beitrag von 88.217.141.156 (Diskussion) 22:48, 21. Okt. 2010 (CEST))

Nur netzwerkbezogen?

Wird der Begriff nur im Zusammenhang mit Netzwerksicherheit verwendet? Ich dachte bisher, dass er auch allgemein verwendet wird, z.B. Verhinderung von Sprengstoffkriminalität durch die (gesetzliche und exekutive) Verhinderung des öffentlich Zugänglichmachens von Sprengstoffrezepten, in großpolitischem Maßstab auch durch das Verbot, Know-how bezüglich Nukleartechnik an beliebige Länder zu liefern, oder allgemein Geheimhaltung industrieller Technologien (als Alternative zum Patent). Mich wundert, dass der Artikel sich auf das Thema Netzwerksicherheit beschränkt.--SiriusB 11:08, 6. Jul. 2008 (CEST)

Wäre das vielleicht ein Beispiel? Wächter, die eine Bank bewachen, und der Feind kennt die Wege. Damit sollte die Sicherheit nicht ausgehebelt werden können. Die Beispiele, bis auf den Blumentopf, sind nicht imo nicht sehr verständlich, da die Folgen fehlen. z.B. >> Konfiguration einer Firewall, so dass Anfragen auf Ports ignoriert (DENY/DROP) anstatt negativ beantwortet werden (REJECT). Das heißt nun was? Der Angreifer soll die verwendeten Ports nicht kennen um.... --129.13.72.198 12:45, 23. Mär. 2010 (CET)

quellenloses brainstorming

Was soll der Quelle-Baustein mit der Bemerkung "quellenloses brainstorming" über dem Artikel? Security through obscurity ist ein tausendfach auch in der Computer-Presse gebrauchter Begriff, der genau das meint, was in dem Artikel diskutiert wird.

Ist das ein sinnloser Beitrag zum einschlägigen Edit-War? Kann man dann nicht hier in der Diskussion was mit Inhalt dazu sagen, statt einfach den Baustein dahin zu pflanzen, nur um den Artikel zu diffamieren? Siehe oben zu "Baustein".

Ich nehme den wieder weg und bitte hier um eine Diskussion dazu, die sowas begründet. -- Jabo 13:52, 25. Jul. 2009 (CEST)

Attrappe

Das Beispiel "Attrappe" ist falsch, da der Login von Windows 95 niemals dazu gedacht war, den Zugriff auf den Rechner abzusichern. Er diente zur Anmeldung an einem eventuellen Netzwerk. Das war so auch bekannt und keineswegs eine Irreführung des Benutzers. --193.174.38.131 10:10, 29. Nov. 2012 (CET)

Den gleichen Kommentar wollte ich auch gerade verfassen. Die Formulierung im Text ist zwar so, dass es dem/den Autoren allem Anschein nach bekannt ist, dass es gar keine Attrappe ist, allerdings weckt der Text den Eindruck, dass es tatsächlich eine wäre.

Eine komplizierte Erklärung. Jedenfalls wäre ich entweder für eine Streichung des Beispiels, oder aber eine nähere Erläuterung, dass es nur in der Wahrnehmung der meisten Nutzer eine Attrappe ist/war, weil die Nutzer sich nicht hinreichend mit dem Thema und dem Sinn der Anmeldung befasst hatten. -- Spiro Trikaliotis (Diskussion) 20:14, 29. Nov. 2012 (CET)

Warum "nicht ganz ernst gemeint"?

Der erste Satz lautet:

Security through Obscurity oder Security by Obscurity (auf deutsch „Sicherheit durch Obskurität“ oder auch „Sicherheit durch Unklarheit“) ist eine nicht ganz ernst gemeinte Bezeichnung für ein Prinzip in der Computer- und Netzwerksicherheit.""

Was ist an dieser Bezeichnung nicht ganz ernst gemeint? Da viele Fachartikel diesen Begriff verwenden, sollte der Fett hervorgehobene Teil im oben genannten Zitat aus dem Artikel entfernt werden. --Soluvo (Diskussion) 23:11, 9. Jan. 2016 (CET)

Der Teil wurde entfernt. erledigtErledigt --Trustable (Diskussion) 16:10, 16. Jan. 2016 (CET)

Danke! --Soluvo (Diskussion) 08:31, 8. Feb. 2016 (CET)

Gegenkonzept weitestgehende Transparenz

Sicherheit durch weitestgehende Transparenz passt nur mäßig als Gegenkonzept zu Security by Obscurity. Das eigentliche Gegenkonzept ist, dass die Sicherheit eines Systems weder an der Geheimhaltung noch an der Offenlegung der Funktionsweise hängt, sondern dass es Secure by Design ist. Geheimhaltung oder Offenlegung beeinflussen also die Sicherheit des Systems nicht. Ob ich es dann tatsächlich geheim halte oder offenlege, ist demnach sicherheitstechnisch folgenlos.
In diesem Zusammenhang wird meines Erachtens Kerckhoffs' Prinzip nicht ganz richtig wiedergegeben. Kerckhoffs' sagt, ein militärisches Verschlüsselungssystem dürfe nicht Geheimhaltung fordern und begründet dies damit, dass es zu vielen Individuen bekannt ist und zu viele Möglichkeiten zur Kompromittierung durch den Feind bietet. Kerckhoffs' sagt nicht: "man muss das System offen legen", sondern sinngemäß: "es muss auch dann noch sicher sein, wenn es offengelegt wurde". Man kann ein Verschlüsselungssystem entwerfen, dessen Sicherheit am Schlüssel hängt und die Funktionsweise dennoch geheimhalten. Dies ist kein Widerspruch zu Kerckhoffs' Prinzip.
Ich finde, der Artikel sollte diese Nuance herausarbeiten, da ansonsten der Fehlschluss verbreitet wird, Sicherheit ließe sich nur durch völlige Offenlegung erreichen (anstatt durch ein sicheres Design) und Transparenz als Gradmesser für Sicherheit gleichgesetzt wird. --Matthäus Wander 15:56, 25. Jul. 2023 (CEST)