[ALG] over de FAQ. Security: open source of niet?

[Anoniem: 27915]

[topic=392390/1/25]

[..]
Risico's in meer detail en het voorkomen ervan.
Geen informatie verstrekken.

Hoewel een hacker/cracker niets hoort te kunnen doen met de gevonden informatie, is het altijd beter dat hij niet meer informatie over een site heeft dan strikt noodzakelijk voor het gebruik van de site. Elk beetje informatie kan een veiligheidsgat blootleggen of de impact van een hack vergroten doordat de hacker veel beter weet wat hij allemaal kan uithalen. Weliswaar is dit dan een fout van de programmeur, maar de hacker zal daar alleen maar dankbaar voor zijn.
[..]

Ik ben het hier niet mee eens. Hier wordt security through obscurity gepredikt! Dat is de meest evil en slechte vorm van beveiliging die er is. Uiteindelijk zal men een beveiligingsgat toch wel vinden - dus wat je het beste kunt doen is om iemand met een redelijke kijk op beveiliging ernaar te laten kijken (want daar gaat het hier dus om), hem alle informatie te geven (+ source-access). Liever snel een goedwillend persoon veel gaten ineens laten vinden dan er achteraf achter komen dat een kwaadwillend persoon een veiligheidsgat vond. Je hoeft niet meteen te opensourcen, maar security through obscurity is achterhaald en per definitie fout.

Mag zoiets misschien in de FAQ worden toegevoegd? Anders krijgen we straks weer een MS generatie van PHP programmeurs die allemaal menen beter te weten hoe beveiliging werkt... Daar zal de wereld niet blij van worden (behalve de crackers). Openheid is altijd beter dan obscurity. .

[Anoniem: 26306]

Dat is natuurlijk iets waar je over kunt discussiëren, en het is nog een interessante discussie ook. De één zal vinden dat je zo weinig mogelijk informatie moet verstrekken, de ander -zoals jij- vind dat je alles zo open moet maken dat anderen (die je misschien inhuurt) je helpen als ze een veiligheidslek zien.

En ik zeg niet dat de ene methode beter is dan de andere, want dat is denk ik erg onderhevig aan een persoonlijke mening.

Misschien is het een idee om er in /14 verder over te discussiëren? (Misschien zijn er al eerdere discussies over?)

[wasigh]

Misschien beter om deze discussie in P&W te voeren?
edit: cheatah was me voor

[whoami]

Op woensdag 05 juni 2002 10:21 schreef Cheatah het volgende:
Misschien is het een idee om er in /14 verder over te discussiëren? (Misschien zijn er al eerdere discussies over?)

Kan inderdaad een leuke discussie worden. Voor zover ik weet loopt er daar momenteel geen discussie over... Dus ik zou zeggen, ga je gang en open een topic.

[justmental]

Op woensdag 05 juni 2002 09:23 schreef beelzebubu het volgende:
[topic=392390/1/25]
[..]

Ik ben het hier niet mee eens. Hier wordt security through obscurity gepredikt! Dat is de meest evil en slechte vorm van beveiliging die er is.
*knip*

Dat is een beetje mijn schuld en inderdaad een hele leuke discussie
Gaat deze gemoved worden of komt er een nieuwe?

[wasigh]

Dat wordt ff wachten op een LA dokter

[Tom]

LA>>P&W

[D2k]

tnx Tom
titel ff gemod

[whoami]

Ik denk dat het niet vrijgeven van source-code eventuele beveiliginslekken toch moeilijker opspoorbaar maakt.

Als je uw broncode open maakt, kunnen anderen die lekken wel vinden en u helpen om ze op te lossen ed, maar wie zegt dat de mensen die de lekken vinden wel allemaal even goede bedoelingen hebben?

[Limhes]

Als bijvoorbeeld toegang wordt verstrekt naar gelang de referer en er komt een melding op het scherm dat de referer niet juist is, kan een cracker de referer gaan faken, terwijl als er gewoon 'authorisation failed' oid. staat de cracker geen aanknopingspunt heeft.
Dit kun je met veel dingen zo doen, dus ik vind het een goede extra beveiliging.

[whoami]

Titel nog iets duidelijker gemaakt...

[justmental]

Laat ik voorzichtig beginnen:
Welke van de volgende cases zouden jullie 'security by obscurity' noemen?:
-De keycard van de admin ligt in een kluis met een cijferslot
-De keycard van de admin ligt verstopt in de sokkenla van de admin
-Het password van het admin account is alleen bekend bij de admin zelf
-Het url van een admin functie is alleen bekend bij de admins

[Glimi]

Op woensdag 05 juni 2002 09:23 schreef beelzebubu het volgende:
[topic=392390/1/25]
Ik ben het hier niet mee eens. Hier wordt security through obscurity gepredikt!

Mijn visie is anders. Hier wordt immers niet verteld dat Securit through Obscurity een oplossing is, maar een middel (let op dat fout van de progger), en dat kan je met de beste wil van de wereld niet ontekken, om het ontdekken van veiligheidslekken te vertragen. Zo hoorde ik gisteren op de Java Dev Day ook dat de enige hacks op de JVM die gepleegd zijn, kwamen doordat men de source had.

Dat is de meest evil en slechte vorm van beveiliging die er is.

Het is niet eens beveiliging.

Uiteindelijk zal men een beveiligingsgat toch wel vinden - dus wat je het beste kunt doen is om iemand met een redelijke kijk op beveiliging ernaar te laten kijken (want daar gaat het hier dus om), hem alle informatie te geven (+ source-access). Liever snel een goedwillend persoon veel gaten ineens laten vinden dan er achteraf achter komen dat een kwaadwillend persoon een veiligheidsgat vond. Je hoeft niet meteen te opensourcen, maar security through obscurity is achterhaald en per definitie fout.

Denk je dat intern in een bedrijf de code niet 10x doorgelicht wordt? Vooral bij grote stukken code (agian de JVM) bekijken echt 10tallen werknemers van SUN deze code en die hebben _echt_ verstand van zaken. Opensource is vaak de laatste stap die je wilt nemen omdat je dan dus ook kwaadwillende een optie geeft.

Mag zoiets misschien in de FAQ worden toegevoegd? Anders krijgen we straks weer een MS generatie van PHP programmeurs die allemaal menen beter te weten hoe beveiliging werkt... Daar zal de wereld niet blij van worden (behalve de crackers). Openheid is altijd beter dan obscurity. .

Denk je echt dat de wereld gaat afhangen van de FAQ? Koel, want die heb ik op spelling gecheckt Maar het lijkt me dan men daar zelf een kanttekening bij moet plaatsen. Men moet zelf inzien dat het niet de juiste weg is door ADMIN als altijd werkend wachtwoord te nemen. Ik denk dan ook dat men wel wat heeft aan deze discussie. En thread lezen ze toch vaker dan de FAQ
Maarja to the point -> Misschien een kleine nuancering in het stukje, maar het is voor mij zeker duidelijk!

[D2k]

_{overigens mag alle overige kritiek over de faq mijn kant op,dus ook linkjes enz}

[mbravenboer]

Ik ben het volledig met de topic-starter eens.

Er zijn in het verleden meer dan genoeg voorbeelden geweest van cryptografische oplossingen die geheim werden gehouden (protocol voor communicatie tussen GSM telefoon en basisstation bijvoorbeeld)om zo een grotere veiligheid te bereiken. Dit is inderdaad security by obscurity.

Een oplossing moet by design goed in elkaar zitten, niet door het waas wat er overheen ligt. Als je er een waas over heen legt heeft dat veel nadelen: (1) Je geeft in feite al aan zelf niet het vertrouwen te hebben dat het design van de oplossing voldoende veiligheid biedt. (2) Andere mensen zoals academici kunnen de veiligheid van de oplossing niet beoordelen en eventueel adviezen geven.

De methode die gebruikt is, kan vrij gemakkelijk uitlekken of uitgevonden worden. Het is noodzakelijk dat de methode op zich dan nog krachtig genoeg is: het 'waas' heeft de methode geen extra kracht.

Op zich kan een goede methode best gesloten zijn, maar het kenmerk van gesloten systeem is over het algemeen juist dat je om wat voor reden dan ook de inhoud van het geslotene niet duidelijk wilt maken aan de mensheid. Helaas staat deze aanpak vaak gelijk aan een gebrek aan vertrouwen in de methode door bijvoorbeeld het ontbreken van formele ondersteuning van de gekozen methode.

[Anoniem: 37864]

Denk je dat intern in een bedrijf de code niet 10x doorgelicht wordt? Vooral bij grote stukken code (agian de JVM) bekijken echt 10tallen werknemers van SUN deze code en die hebben _echt_ verstand van zaken. Opensource is vaak de laatste stap die je wilt nemen omdat je dan dus ook kwaadwillende een optie geeft.

Ik weet wel zeker (uit ervaring) dat dat bij een boel bedrijven niet gebeurt. Ik heb tot nu toe aan grote projecten gewerkt bij een bekend webdesign bedrijf, een ISP en een groot ziekenhuis en bij alle projecten die ik daar gedaan heb vinden geen code audits plaats en als er met meerderen aan een project wordt gewerkt bekommert iedereen zich om zijn eigen stukje...
Het probleem met het auditten van code is dat je daarvoor een (paar) *goede* werknemer(s) een poosje kwijt bent, het het halen van een deadline niet tengoede komt en ook nog eens extra geld kost.
Het niet vrijgeven van code is in zo'n geval (hoe fout het ook is) een goede extra maatregel.

[justmental]

Op woensdag 05 juni 2002 13:11 schreef mbravenboer het volgende:
Ik ben het volledig met de topic-starter eens.

Er zijn in het verleden meer dan genoeg voorbeelden geweest van cryptografische oplossingen die geheim werden gehouden (protocol voor communicatie tussen GSM telefoon en basisstation bijvoorbeeld)om zo een grotere veiligheid te bereiken. Dit is inderdaad security by obscurity.
*knip*

Mooie uitleg van security by obscurity

Op principieel & fundamenteel gebied vind ik ook dat je gelijk hebt.
Door de toenemende complexiteit van informatiesystemen is tegenwoordig in de praktijk bijna geen enkel systeem echt veilig.
Het niet onnodig vrijgeven van allerlei informatie kan dan een manier zijn om goedkoop de kans op een succesvolle inbraak en de impact daarvan goed verkleinen.
Zo vervagen de grenzen van security by obscurity.

Een inbraak kan ook buiten de technische systemen om gedaan worden.
Dan ligt het geheimhouden van een password wel erg dicht bij het geheimhouden van een sessionid of een url.

Voor organisaties waarbij een hoge graad van security nodig is vind ik de traditionele security principes nog goed toepasbaar, maar op het gebied van website-security is denk ik een nuancering nodig.
_{Toch zie je dat ook deze organisaties (bv. banken) ook obscurity nog gebruiken}
Tegenwoordig staat de uiteindelijke (kosten)effectiviteit van een security-maatregel boven het principiele.

Dus theoretisch zijn security by obscurity en alle grijze gebieden er omheen geen security, maar in de praktijk kunnen ze hun waarde zeker hebben.
Daarom vind ik het op z'n plaats in de faq.

[whoami]

Maar het is toch zo dat een cracker ook uw broncode kan gaan doorspitten met als doel om beveiliginslekken op te sporen?
Als je de broncode niet vrijgeeft, gaat dat toch al een stuk moeilijker?

Ik zie het niet vrijgeven van broncode niet als een een vervangmiddel tegen een slecht design van de beveiliging, maar eerder als een extra. Een goed design + geen open source.

[Glimi]

Op woensdag 05 juni 2002 13:37 schreef whoami het volgende:
Maar het is toch zo dat een cracker ook uw broncode kan gaan doorspitten met als doel om beveiliginslekken op te sporen?
Als je de broncode niet vrijgeeft, gaat dat toch al een stuk moeilijker?

Ik zie het niet vrijgeven van broncode niet als een een vervangmiddel tegen een slecht design van de beveiliging, maar eerder als een extra. Een goed design + geen open source.

Inderdaad! Ik vind het eerder een mogelijke aanvulling in plaats van een vervanging van de beveiliging

[mbravenboer]

whoami: Maar het is toch zo dat een cracker ook uw broncode kan gaan doorspitten met als doel om beveiliginslekken op te sporen? Als je de broncode niet vrijgeeft, gaat dat toch al een stuk moeilijker?

Het gaat in de redenatie van security by obscurity vooral om cryptografische algorithmen, maar ook in andere gevallen kan je de lijn best doortrekken. Inderdaad is het zo dat 'slechte mensen' je code kunnen gaan doorzoeken met slechte bedoelingen. Zeker bij cryptografische algorithmen of essentiele beveilingsonderdelen zijn er echter nog veel meer 'goede mensen' die je code of algorithme doorkijken en tips en adviezen kunnen geven. In het concrete GSM voorbeeld hadden academici bijvoorbeeld hele waardevolle tips kunnen geven als het protocol in een open vorm ontwikkeld was.

Ik zie het niet vrijgeven van broncode niet als een een vervangmiddel tegen een slecht design van de beveiliging, maar eerder als een extra. Een goed design + geen open source.

Je kan niet in je eentje beoordelen of iets een goed design zijn. Als je iets gesloten houdt, ben jij de enige die kennis heeft van het protocol (voor zolang het duurt). Helaas kan je als individu (en zelfs niet als groot bedrijf) in veel gevallen niet beoordelen of iets goed in elkaar zit omdat simpelweg de kennis vaak ontbreekt.

De kennis van de gemeenschap, en in het bijzonder die van onderzoekers en beveiligings-deskundingen, is vele malen groter...

[Soultaker]

Even for the record: gaat dit topic nog om de eerste post (over de FAQ; waarmee ik het oneens ben) of is het nu een topic over security by obscurity geworden?

Wat het laatste betreft ben ik het eens met het argument dat je beveiliging niet moet laten afhangen van obscurity, maar ik kan me heel goed voorstellen dat het geheimhouden van code net een extra zekerheid geeft, bovenop de beveiliging die de gebruikte cryptografie zelf al biedt.

Zelfs als de broncode niet beschikbaar is, kan een bedrijf natuurlijk (eventueel permanent) beveilingsprofessionals in dienst kan hebben die de (heldere) broncode doorzoeken op mogelijke tekortkomingen. Dat lost het probleem van de controleerbaarheid niet op, maar het zal in het algemeen wel voorkomen dat de makers iets 'over het hoofd' zien.

Uiteindelijk is elke cryptografie natuurlijk te kraken, maar om een geschikte methode te vinden, zul je eerst moeten uitvinden hoe de code werkt. Als dit al erg moeilijk is, is de kans aanwezig dat een deel van de mogelijke crackers al afhaakt voordat met de daadwerkelijke cryptoanalyse kan worden begonnen, vooral omdat een intelligent wiskundige in het algemeen geen expert in het lezen van (zo obscuur mogelijk gemaakte) assembly code is.

[mbravenboer]

Glimi: Inderdaad! Ik vind het eerder een mogelijke aanvulling in plaats van een vervanging van de beveiliging

Een goede beveiliging moet gebaseerd zijn op het geheim houden van zo weinig mogelijk informatie (zoals bijvoorbeeld gebruikte keys). Je kan op basis van deze minimale niet toegankelijke informatie redeneren over de veiligheid van een systeem.

Over het geheim houden van methoden of code kan je niet redeneren. Het voegt qua veiligheid helemaal niets toe, behalve dat je aangeeft dat je liever niet anderen bekend maakt met de 'veilige' methode die jij toepast. Omdat het niets toevoegd aan de veiligheid van systeem kan je de methode beter maar bekend maken omdat de geheimhouding een vals gevoel van veiligheid geeft.

Kijk bijvoorbeeld eens naar Mozilla, SSH en PGP. In alle drie de systemen zijn recentelijk gebreken geconstateerd. Zijn ze gevonden door hackers? Nee, ze zijn gevonden door experts (zeker in het geval van PGP). Het systeem is hierdoor weer een stuk veiliger geworden en dit was nooit gebeurd als de methoden en de code niet open waren geweest.

[MSalters]

Het is in dit verband misschien nuttig te realiseren dat noch DES noch AES ooit geheim gehouden zijn. Als cracker zou ik geneigd zijn om juist te zoeken naar security leaks in closed source software; daar zijn ze veel gangbaarder. In open-source is er altijd wel een white-hat die ze fixed.

[Soultaker]

Op woensdag 05 juni 2002 13:55 schreef mbravenboer het volgende:
Het systeem is hierdoor weer een stuk veiliger geworden en dit was nooit gebeurd als de methoden en de code niet open waren geweest.

Met openbare code zijn deze fouten ook veel makkelijker te misbruiken. Als de broncode niet beschikbaar zou zijn geweest, is de kans groot dat de fouten nooit misbruikt zouden zijn, al was het alleen maar omdat ze niet ontdekt zouden zijn.

In principe ben ik het met je eens dat je daar vanuit theoretisch oogpunt weinig mee opschiet, maar in een situatie waarin het er vooral om gaat dat de beveiliging niet wordt gecompromitteerd, is het aantrekkelijker om fouten nooit naar boven te laten komen dan om een fouten te herstellen. Zeker als hier de reputatie van een bedrijf of produt mee gemoeid is.

Ik keur deze strategie niet goed, maar ik kan me heel goed voorstellen dat deze gebruikt wordt. Als voorbeeld hierbij wil ik het gebruik van allerlei ingewikkelde checksums (gemodificeerde MD5, dacht ik?) in het Quake III Arena netwerkprotocol aanvoeren. Theoretisch is het een beveiliging van niets, aangezien de checksums wel na te maken zijn, maar door het dissassembleren van de code te verbieden, is het wel lange tijd mogelijk geweest om te voorkomen dat het protocol werd gebruikt om vals mee te spelen. De inhoud van het protocol was al snel volledig geanalyseerd, maar het feit dat de cheksums in principe door obscurity werden beveiligd, zorgde ervoor dat het in de praktijk (op legale wijze) nauwelijks te emuleren was. In dit specifieke voorbeeld was de 'gemeenschap' van spelers (die het aantal valsspelers in grootte veruit overtreft) zeker gebaat bij obscurity.

[Anoniem: 13700]

Ik mis een belangrijk argument tegen security through obscurity. Zeker is het mogelijk om in de source code op zoek te gaan naar vulnarabilities, maar dat kan ook met de binary. Het is slechts onwezenlijk moeilijker om de binary eerst door een disassembler te halen voordat je op zoek gaat naar bv. het aanroepen kwetsbare libc functies.

[mbravenboer]

Ach, ik denk dat de 'gemeenschap van spelers' nog meer geholpen was geweest met een degelijk beveiligd protocol, wat absoluut niet lastig hoeft te zijn. Gebruik van standaard protocollen en standaard software daarvoor is de eenvoudigste en goedkoopst manier om veiligheid te bereiken (bij goede keuze en gebruik van de methoden uiteraard).

Ik snap de redenatie overigens best dat gesloten methoden net een drempel kunnen vormen, maar hackers laten zich niet tegenhouden door gesloten methoden en voelen zich daartoe zelfs aangetrokken. Het is een kwestie van tijd voordat een (veel gebruikte) methode op straat ligt en het is dan belangrijk dat je methode voldoende veilighied van zichzelf bezit. Om je hier gelijk van te verzekeren, is het net zo zinvol om de zaak dan maar gelijk open te maken.

[justmental]

Op woensdag 05 juni 2002 14:15 schreef mietje het volgende:
Ik mis een belangrijk argument tegen security through obscurity. Zeker is het mogelijk om in de source code op zoek te gaan naar vulnarabilities, maar dat kan ook met de binary. Het is slechts onwezenlijk moeilijker om de binary eerst door een disassembler te halen voordat je op zoek gaat naar bv. het aanroepen kwetsbare libc functies.

Dat klopt.
De discussie is enigszins heen en weer aan het zweven
Orgineel ging het over het gequote stukje tekst uit de faq.
Dat stukje gaat over website security.
Daarbij heb je over het algemeen de mogelijkheid om je code niet openbaar te maken, dus ook geen binaries.

[Glimi]

Op woensdag 05 juni 2002 13:55 schreef mbravenboer het volgende:
Een goede beveiliging moet gebaseerd zijn op het geheim houden van zo weinig mogelijk informatie (zoals bijvoorbeeld gebruikte keys). Je kan op basis van deze minimale niet toegankelijke informatie redeneren over de veiligheid van een systeem.

Over het geheim houden van methoden of code kan je niet redeneren. Het voegt qua veiligheid helemaal niets toe, behalve dat je aangeeft dat je liever niet anderen bekend maakt met de 'veilige' methode die jij toepast. Omdat het niets toevoegd aan de veiligheid van systeem kan je de methode beter maar bekend maken omdat de geheimhouding een vals gevoel van veiligheid geeft.

Mwoah, het kan zeker iets toevoegen, namelijk een barriere voor de cracker/hacker. Het zal hem in ieder geval flink meer tijd gaan kosten om een potentiele zwakke plek te ontdekken.

Echter inderdaad schrik je hier eerder de goeie, dan de kwaden mee af, aangezien de kwade toch wel bereid zijn er moeite voor te doen, ook al is het niet gewenst door het desbetreffende bedrijf.

Kijk bijvoorbeeld eens naar Mozilla, SSH en PGP. In alle drie de systemen zijn recentelijk gebreken geconstateerd. Zijn ze gevonden door hackers? Nee, ze zijn gevonden door experts (zeker in het geval van PGP). Het systeem is hierdoor weer een stuk veiliger geworden en dit was nooit gebeurd als de methoden en de code niet open waren geweest.

Dat is natuurlijk niet totaal representatief. PGP en Mozilla zijn kindjes van de Opensource wereld en er werken meer dan duizenden mensen aan, met een grote schare fans.
Zo werd gisteren op de Java Dev Day verteld dat de JVM een paar keer gehackt was doordat sommige mensen de code hadden. Deze hadden het braaf gemeld, maar Sun niet de kans gegeven om een patch uit te brengen (bijv 3 dagen later op bugtraq gooien). Dit vind ik dus ook niet netjes en vind ik ook onder misbruik vallen

[Anoniem: 29908]

als je iets closed-source maakt is het voor crackers alleen maar interessanter.

het gaat om de uitdaging, en met een stukje closed-source is die uitdaging alleen maar groter

[Bobco]

Op woensdag 05 juni 2002 13:31 schreef Qlone het volgende:
[..]
Het probleem met het auditten van code is dat je daarvoor een (paar) *goede* werknemer(s) een poosje kwijt bent, het het halen van een deadline niet tengoede komt en ook nog eens extra geld kost. Het niet vrijgeven van code is in zo'n geval (hoe fout het ook is) een goede extra maatregel.

Ik ben het met je eens dat een code review tijd kost, veel tijd zelfs als je het serieus neemt. Het heeft echter wel een aantal niet te onderschatten voordelen:

- meer mensen zien de code waardoor je fouten, overtredingen van afgesproken regels en slechte opzet van programma's op kan sporen.

- meer mensen zijn tot op een redelijk detailniveau op de hoogte van grotere stukken van een systeem.

- je leert sneller van elkaars fouten of briljante invallen.

Of het wel of niet doen van peer reviews het vrijgeven van code beinvloedt? Lijkt me van niet. Veel open source programmatuur is van algemene aard: OS'en, utilities in de meest brede zin van het woord en algemene toepassingen die overal worden gebruikt. Bedrijven schrijven meestal heel specifieke software voor het ondersteunen van bedrijfsspecifieke processen, die niet kan worden gedaan met een standaardpakket. De kennis die in dat soort software zit geeft vaak heel veel aan over hoe een be3drijf intern werkt. Ik kan me dan ook heel goed voorstellen dat juist dit soort in-huis geschreven software niet openbaar wordt gemaakt. Dat heeft niets met keuzes tussen closed/open source te maken, mar alles met het bewaren van echte bedrijfsgeheimen.

[ACM]

Wel een grappige kanttekening:

Ik zie regelmatig op de security-delen van de Bugtraqmailinglist opmerkingen voorbij komen waarmee aangeduidt wordt dat de gevonden vulnerability al een maand eerder aan de makers gegeven was zodat die tijd hadden het te fixen.
Daarna wordt vaak pas de vulnerability openbaar gemaakt op die lijst, met een detail beschrijving, voorbeeld exploit en verwijzing naar de gefixte versie van de software.

Is dat niet ook een variant van security through obscurity?
Als je direct op het moment dat je het gat gevonden hebt de boel aan de wereld bekend maakt kunnen er allerlei ernstige dingen uit volgen. Ondanks dat het opensourced software was en de intentie van de bugvinder de beste van de wereld geweest kan zijn.


Ik heb dat stukje in de FAQ verwerkt vanwege de hier genoemde 'voordelen', met idd de 'nadelen' wel in het achterhoofd.
Overigens betekend de tekst helemaal niet dat de source niet open mag zijn
(fictief voorbeeld) Echter ben je dom bezig als je de wereld gaat vertellen dat jouw apache versie 1.3.23 is en dus een versie is die de nog de bekende scripting exploit heeft waarmee men via de 'GET /?cmd=cmd.exe' exploits de boel kan verpesten op je linux doos...

DAT is wat ik primair bedoel met niet meer info verstrekken dan noodzakelijk. Er zijn zoveel voorbeelden te bedenken waar je gewoon geen informatie over moet geven.
- De gebruikersnamen van andere gebruikers (want stel eentje heeft een password ala 'henk1' terwijl hij als gebruikersnaam 'henk' heeft... en ja, dit is ook security by obscurity )
- Versienummers van je kernel tonen in de websoftware bijv.
- etc
- etc

[ACM]

Op woensdag 05 juni 2002 16:07 schreef Bobco het volgende:
Dat heeft niets met keuzes tussen closed/open source te maken, mar alles met het bewaren van echte bedrijfsgeheimen.

En dat is een ander aspect van 'veiligheid'

[Anoniem: 27915]

Damn, wat gaat dat snel. . Ik kan ook geen middaje weg zijn. .

Denk je dat intern in een bedrijf de code niet 10x doorgelicht wordt? Vooral bij grote stukken code (agian de JVM) bekijken echt 10tallen werknemers van SUN deze code en die hebben _echt_ verstand van zaken. Opensource is vaak de laatste stap die je wilt nemen omdat je dan dus ook kwaadwillende een optie geeft.

Mijn ervaring is dat dat niet zo is. Opensource is vaak iets wat je om meerdere redenen wilt voorkomen (laat ik hier geen opensource vs. closed source discussie van maken), maar met name bij kleine bedrijven zijn deze security experts er niet. Die moet men inhuren. Of niet. En als het toch closedsource blijft, waarom dan die extra kosten? Ook bij Microsoft zie je het. Grappig genoeg zijn in IIS, wat minder gebruikt wordt en closedsource is, meer gaten bekend dan in Apache, wat meer gebruikt wordt, complexer is en opensource is... Het geeft aan dat veel bedrijven security through obscurity toch blijkbaar als reden zien om dan maar de security wat minder aandacht te geven... En daar zit hem de grote fout, dat is supergevaarlijk. En dat weten we allemaal!

Maarja to the point -> Misschien een kleine nuancering in het stukje, maar het is voor mij zeker duidelijk!

Omdat jij weet waar je mee bezig bent, jij wet er veel vanaf. De meeste mensen (en dan vooral de mensen die de FAQ moeten lezen) niet...

Overigens ben ik het met je eens dat security through obscurity, of closedsource, whatever, het vinden van lekken wel kan vertragen. Maar uiteindelijk komen ze toch wel aan het licht. Dan is het inzicht geven in de code aan experts een enorm goed middel. Veel bedrijven doen dat - vele anderen niet. In zoverre ben ik het dus met Limhes eens - het is een goede extra beveiliging.

Om met mbravenboer's woorden te spreken, een oplossing moet by design goed in elkaar steken. De enige manier (imho) om dit te bereiken is door jezelf kwetsbaar op te stellen, dan komen nl. de gaten pas aan het licht - en dus moet je inzicht geven in de code, tenminste aan een select stel experts, maar misschien wel aan iedereen. Opensourcing of experts inhuren (of in dienst nemen bij grotere bedrijven). Het is allemaal een oplossing.

Als laatste, wat ACM zegt over bugtraq klopt - velen zien de obscurity als probaat middel om niet teveel naar de security te hoeven kijken - en dat is dus een fout, dat heb ik al eerder gezegd. Als toevoeging aan je security model, dus om het moeilijker te maken, kan het werken. Maar het mag niet op zichzelf staan, dat werkt gewoon niet.

Om dus terug te komen naar het originele topic, ik denk dat een nuancering of kanttekening als toevoeging uit het gequote stukje uit de FAQ zeker een goed idee zou zijn. Zoals het nu in de FAQ staat kan het misleidend zijn omdat het lijkt alsof 'geen informatieverstrekking' op zich een goed middel tegen crackers is - dat is dus niet zo.

[ACM]

Op woensdag 05 juni 2002 17:39 schreef beelzebubu het volgende:
Zoals het nu in de FAQ staat kan het misleidend zijn omdat het lijkt alsof 'geen informatieverstrekking' op zich een goed middel tegen crackers is - dat is dus niet zo.

Daar heb je me nog steeds niet van overtuigd

Imho is dat wel zo.
Dat je het niet door moet laten slaan naar een 'security throug obscurity' die de echte veiligheidspolicies vervangen is wat anders...

[Anoniem: 27915]

Op woensdag 05 juni 2002 17:53 schreef ACM het volgende:
Daar heb je me nog steeds niet van overtuigd

Ik druk me volgens mij wat ongelukkig uit, ik bedoel dus dat het in de FAQ nu lijkt alsof security through obscurity op zichzelf een goed beveiligingsmiddel is. Mijns inziens is het hoogstens een hulpmiddel als toevoeging op de eigenlijke beveiliging.

[Anoniem: 27915]

* Anoniem: 27915 schopje *

ACM, ga je nu wel of niet een kleine toevoging aan de FAQ maken waarin staat dat secutiry through obscurity op zichzelf geen afdoende beveiligingsmethode is maar dat het meer toevoeging op de eigenlijke beveiliging kan zijn?

* Anoniem: 27915 schopje *

[ACM]

Op vrijdag 07 juni 2002 15:44 schreef beelzebubu het volgende:
* ACM schopje *

ACM, ga je nu wel of niet een kleine toevoging aan de FAQ maken waarin staat dat secutiry through obscurity op zichzelf geen afdoende beveiligingsmethode is maar dat het meer toevoeging op de eigenlijke beveiliging kan zijn?

* ACM schopje *

ook klein schopje, ja ik wil dat best doen

Maar heb het een beetje druk

[Anoniem: 27915]

Op zondag 09 juni 2002 19:03 schreef ACM het volgende:
ook klein schopje, ja ik wil dat best doen

Maar heb het een beetje druk

Als ik een klein stukje erbij schrijf, accepteer je het dan? D2k kan dan de tekst in de FAQ plaatsen. .

Iets van:

Geen informatie verstrekken.

Hoewel een hacker/cracker niets hoort te kunnen doen met de gevonden informatie, is het altijd beter dat hij niet meer informatie over een site heeft dan strikt noodzakelijk voor het gebruik van de site. Elk beetje informatie kan een veiligheidsgat blootleggen of de impact van een hack vergroten doordat de hacker veel beter weet wat hij allemaal kan uithalen. Weliswaar is dit dan een fout van de programmeur, maar de hacker zal daar alleen maar dankbaar voor zijn.

<toevoeging begint hier>
Dit neemt niet weg dat het over het algemeen een goed idee kan zijn om anderen naar je code te laten kijken. Dit hoeft niet te betekenen dat je meteen je code opensourcet, maar vier ogen (of meer) zien meer dan twee. Als je aan grotere projecten werkt in grotere teams, is het niet ongebruikelijk dat er een veiligheidsexpert in dienst wordt genomen om de security kant van de code door te nemen.

Het feit dat een cracker/hacker jouw code niet kan zien betekent niet dat hij de veiligheidsgaten niet kan vinden - het duurt slechts wat langer! Oftewel, closed source code verandert niks aan het security principe, hier moet je altijd op letten! Closed source code is op zichzelf absoluut geen beveiliging, het kan slechts een toevoeging zijn op andere beveiligingsmethoden!
</toevoeging eindigt hier>

Zoiets? .

[ACM]

Geen informatie verstrekken.

Hoewel een hacker/cracker niets hoort te kunnen doen met de gevonden informatie, is het altijd beter dat hij niet meer informatie over een site heeft dan strikt noodzakelijk voor het gebruik van de site. Elk beetje informatie kan een veiligheidsgat blootleggen of de impact van een hack vergroten doordat de hacker veel beter weet wat hij allemaal kan uithalen. Weliswaar is dit dan een fout van de programmeur, maar de hacker zal daar alleen maar dankbaar voor zijn.

[toevoeging begint hier]
Dit neemt niet weg dat het over het algemeen een goed idee kan zijn om anderen naar je code te laten kijken. Dit hoeft niet te betekenen dat je meteen je code opensourcet, maar vier ogen (of meer) zien meer dan twee. Als je aan grotere projecten werkt in grotere teams, is het niet ongebruikelijk dat er een veiligheidsexpert in dienst wordt genomen om de security kant van de code door te nemen.

Wat sourcecode betreft betekent dit dus dat zelfs als een cracker/hacker jouw code niet kan zien, hij de veiligheidsgaten nog steeds kan vinden - het duurt hooguit wat langer! Oftewel, closed source code verandert niks aan het security principe, hier moet je altijd op letten! Closed source code is op zichzelf absoluut geen beveiliging, het kan slechts een toevoeging zijn op andere beveiligingsmethoden!
[/toevoeging eindigt hier]

Klein beetje veranderd, bij jou was het net of mijn stukje over informatie alleen maar over de source zelf ging
D2k, faqze

[D2k]

Op zondag 09 juni 2002 20:16 schreef ACM het volgende:
D2k, faqze

done

* D2k is snel

[Anoniem: 27915]

Danku. .

* Anoniem: 27915 is weer helemaal blij. .

[D2k]

is het een id om dit er nog onder te vermelden als discussie topic

[ACM]

Op maandag 10 juni 2002 10:49 schreef D2k het volgende:
is het een id om dit er nog onder te vermelden als discussie topic

Kan je best doen.

[Anoniem: 7195]

Op woensdag 05 juni 2002 09:23 schreef beelzebubu het volgende:
[topic=392390/1/25]
[..]
Ik ben het hier niet mee eens. Hier wordt security through obscurity gepredikt! Dat is de meest evil en slechte vorm van beveiliging die er is.

Says who? De GPL-zealotbrigade? De 'many eyes'-theorie van ESR is al omvergeworpen doordat ook nu nog steeds oude bugs opduiken in open source software, domweg omdat maar een handjevol mensen de sources bekijken, wat neerkomt op ong. het aantal developers dat bezig is bij grote softwarehouses.

Uiteindelijk zal men een beveiligingsgat toch wel vinden -

Oh? Als je een cracker (en dus geen scriptkiddie) aan het werk hebt gezien (of zelf bent geweest) weet je dat een disassembly OF een sourcelisting geen verschil maakt. Dus closed of open source boeit niet. Wat boeit is het belang dat is gemoeid met de vondst van een lek. Het is daarom juist DOM om te prediken dat open source veiliger is, want dat schept een gevoel van veiligheid (doordat open source wordt gebruikt) terwijl dat in feite ongegrond is: het maakt nl. geen verschil.

dus wat je het beste kunt doen is om iemand met een redelijke kijk op beveiliging ernaar te laten kijken (want daar gaat het hier dus om), hem alle informatie te geven (+ source-access). Liever snel een goedwillend persoon veel gaten ineens laten vinden dan er achteraf achter komen dat een kwaadwillend persoon een veiligheidsgat vond. Je hoeft niet meteen te opensourcen, maar security through obscurity is achterhaald en per definitie fout.

Maar wat heeft dit met open source te maken? Oracle heeft net als Microsoft bijvoorbeeld testers in dienst die puur zoeken naar dit soort gaten. (Ook 3rd parties doen die tests op verzoek).

Je gepiep dat security through obscurity achterhaald is en per definitie fout is een foutieve constatering in deze context: het heeft niets te maken met open of closed source. Ik kan in open source software OOK security through obscurity toepassen, domweg door een stukje obfuscated code toe te voegen dat mn security regelt. Jij doelt op het inderdaad achterhaalde principe: 'men heeft de source niet en dus snapt men de beveiliging niet/de security niet', maar dat is al sinds de commodore 64 achterhaald en wordt heden ten dage allang niet meer toegepast omdat, zoals ik eerder zei, voor een echte cracker het niet boeit of de source wel of niet beschikbaar is.

Het door zealots als ESR gepredikte 'closed source is insecure because security through obscurity is wrong and insecure' staat los van Open Source vs Closed Source. Jij betrekt die laatste discussie onterecht bij de discussie welk security model goed/slecht is.

Mag zoiets misschien in de FAQ worden toegevoegd? Anders krijgen we straks weer een MS generatie van PHP programmeurs die allemaal menen beter te weten hoe beveiliging werkt... Daar zal de wereld niet blij van worden (behalve de crackers). Openheid is altijd beter dan obscurity. .

Wat een gelul zeg. Je snapt zelf de ballen van security mbt closed source en open source en hoe closed source wordt gebouwd normaliter, maar wel het hoogste woord mbt het veroordelen ervan.

Ik zou graag zien dat de wereld eens verlost werd van die blinde predikanten die maar domweg 'oplossingen' aandragen voor problemen die een heel andere oorzaak hebben dan die stinkende oplossingen suggereren.

* Anoniem: 7195 , Open Source developer.

[ACM]

Op maandag 10 juni 2002 12:05 schreef Otis het volgende:

Zo heb ik het er ook in dat artikeltje bijgeplakt

closed source is niet veiliger, maar ook niet onveiliger

[Anoniem: 7195]

Op woensdag 05 juni 2002 17:39 schreef beelzebubu het volgende:
Mijn ervaring is dat dat niet zo is. Opensource is vaak iets wat je om meerdere redenen wilt voorkomen (laat ik hier geen opensource vs. closed source discussie van maken)

Dat is dan te laat, je initiele posting in deze thread doet JUIST dat, terwijl je feitelijke discussie totaal daar los van staat.

maar met name bij kleine bedrijven zijn deze security experts er niet. Die moet men inhuren. Of niet. En als het toch closedsource blijft, waarom dan die extra kosten? Ook bij Microsoft zie je het. Grappig genoeg zijn in IIS, wat minder gebruikt wordt en closedsource is, meer gaten bekend dan in Apache, wat meer gebruikt wordt, complexer is en opensource is...

Nee. In IIS zelf zitten minder gaten dan in Apache. De extensies van IIS zitten soms wel vol gaten. Dit is veelal zeer oude code (zoals de .htr parsers) die allang niet meer is geupdate en ook zelden wordt gebruikt. Apache is minder complex dan IIS, (pas in 2.0 is apache qua complexiteit op gelijke voet gekomen). De ultieme illusie verder is dat OMDAT apache open source is, er minder leaks in VERWACHT kunnen worden. Dit is de meest dikke plaat beton die je voor je knar kunt hebben hangen. Immers: doe eens een schatting van het aantal mensen die de sourcecode van Apache snappen, en daardoor security leaks kunnen vinden. Doe ook eens een schatting van het aantal developers bij bv Microsoft die de IIS code snappen, plus het aantal testers en automatische testprogramma's die de code uitpersen. Ik denk dat de balans wel eens negatief voor Apache kan uitvallen.

MS heeft nu aangekondigd alle oude buttcode uit veel software te verwijderen en dat is niet meer dan terecht. Het is nl. veelal juist die code die telkens weer opduikt als de leak-provider.

Het geeft aan dat veel bedrijven security through obscurity toch blijkbaar als reden zien om dan maar de security wat minder aandacht te geven... En daar zit hem de grote fout, dat is supergevaarlijk. En dat weten we allemaal!

Je snapt niet wat security through obscurity is. Hint: dat is NIET een stuk software closed source releasen, immers een op bv RSA gebaseerde encryptie is closed source dan wel open source even veilig.

[..]
Omdat jij weet waar je mee bezig bent, jij wet er veel vanaf. De meeste mensen (en dan vooral de mensen die de FAQ moeten lezen) niet...

... waaronder jij. (nofi).

Overigens ben ik het met je eens dat security through obscurity, of closedsource, whatever, het vinden van lekken wel kan vertragen.

Closed source != security through obscurity! Een cracker interesseert het niet of het in C dan wel assembler is, een debugger attachen aan een executable en maar breakpoints zetten kan net zo goed en iemand die weet wat hij doet is net zo snel in het vinden van bugs dan wanneer je de source erbij hebt. Sterker: sneller. Dit omdat je at runtime ziet wat code doet, door programma-text te lezen DENK je dat je snapt wat de code doet, maar na een paar 1000 regels code ben je echt essentiele details vergeten.

Maar uiteindelijk komen ze toch wel aan het licht. Dan is het inzicht geven in de code aan experts een enorm goed middel. Veel bedrijven doen dat - vele anderen niet. In zoverre ben ik het dus met Limhes eens - het is een goede extra beveiliging.

Symptoombestrijding.
Een goed security model ONTWERP je vooraf, en laat dat doorzagen door experts. DAARNA ga je het implementeren en TEST je de implementatie ervan. Alleen maar achteraf kijken of programmeurs een steekje hebben laten vallen is niet genoeg en zelfs dom: het geeft een vals gevoel van veiligheid. Veel leaks zijn het 'anders' gebruiken van functionaliteit, waardoor een correcte implementatie niet goed functioneert in alle gevallen. Andere leaks zijn bugs in de implementatie en implementaties die zaken met data uithalen die, bij het lezen van dissassembly/source + debugger laten zien hoe de security kan worden omzeild. (bv encryptie van passwords die te decrypten is).

Om met mbravenboer's woorden te spreken, een oplossing moet by design goed in elkaar steken. De enige manier (imho) om dit te bereiken is door jezelf kwetsbaar op te stellen, dan komen nl. de gaten pas aan het licht - en dus moet je inzicht geven in de code, tenminste aan een select stel experts, maar misschien wel aan iedereen. Opensourcing of experts inhuren (of in dienst nemen bij grotere bedrijven). Het is allemaal een oplossing.

Open sourceing van software lost NIETS op. Het door laten zagen van je ontwerp door experts en het verifyen van implementaties ervan door testrobots en groepen testers WEL. Alleen dan weet je zeker dat je ALLE zaken test die je wilt testen, immers die definieer je vooraf. Open sourceing geeft die garantie NIET. Misschien kijkt iemand er pas na 2 jaar na. Ben je wel 2 jaar vulnerable geweest.

.NET is een goed voorbeeld van hoe het wel moet: security vanaf het begin hoogste prioriteit geven, design dichttimmeren en testen op flaws, daarna implementeren en dmv testrobots en testteams kijken waar de implementatie tekort schiet. Je kunt dan VOORAF bepalen dat WAT je test ook alles is wat je moet testen en achteraf, dus na het testen, bepalen of hetgeen je oplevert klopt met vooraf gestelde specs.

Het maar open sourcen en hopen dat een groepje mensen het bekijken EN ook nog aan jou rapporteert is niet een garantie dat je ALLES test en na die test ook zeker weet dat het correct is. Die garantie kun je, zover mogelijk, wel geven bij closed source, niet bij open source.

Als laatste, wat ACM zegt over bugtraq klopt - velen zien de obscurity als probaat middel om niet teveel naar de security te hoeven kijken - en dat is dus een fout, dat heb ik al eerder gezegd. Als toevoeging aan je security model, dus om het moeilijker te maken, kan het werken. Maar het mag niet op zichzelf staan, dat werkt gewoon niet.

Nee, dat wisten de spelletjesmakers op de C64 al dat dat niet werkte, want binnen no time waren beveiligingen op basis van simpele obscurity protection schema's gekraakt. Dus wat is je punt?

Om dus terug te komen naar het originele topic, ik denk dat een nuancering of kanttekening als toevoeging uit het gequote stukje uit de FAQ zeker een goed idee zou zijn. Zoals het nu in de FAQ staat kan het misleidend zijn omdat het lijkt alsof 'geen informatieverstrekking' op zich een goed middel tegen crackers is - dat is dus niet zo.

Huh? 'Geen informatieverstrekking' is de ENIGE manier om crackers buiten de deur te houden. Ten eerste worden de meeste systemen juist gekraakt door crackers die gewoon opbellen en middels een smoesje essentiele info ontfutselen (informatieverstrekking) en ten tweede is het zaak GEEN info te verstrekken waaruit ook maar de kleinste details kunnen worden ontleend, waardoor je crackers buiten de deur houdt.

Jij focust puur op bugs in implementaties (buffer overflows etc). Dat is echter maar een deel van de leaks waar het over gaat en dat heeft OOK al geen moer met security through obscurity te maken.