Grappig maar vast niet leuk is dat het zelfde van linux gezegd kan worden. Nooit ontworpen en bedacht om secùrity By design te doen maar enkel om iets gratis te hebben
Torvald schijnt niets met secùrity op te hebben is een dispuut met grsecurity gestart.

Prachtige die simple crypt functies voor passwords welke niet eens op lengteinvoer of andere zaken echt gevalideerd worden. Trial en error gaat over in onvermoede errors.

Waarom moet het toch altijd zo zijn de laatste tijd op dit forum dat een artikel over Microsoft direct een reactie geeft hoeveel beter Linux is en andersom?

Waarom lijkt dit meer op een religiestrijd dan daadwerkelijk op een zinvolle discussie? Bijvoorbeeld over het feit dat in de betreffende blogpost an sich ook onjuiste dingen staan? Wat aantoont dat iedereen een tunnelvisie heeft.

Want is DES echt ongeschikt voor encryptie? Voor informatie waarvan de vertrouwelijkheid heel beperkt is of alleen heel kort relevant is, is DES wellicht bruikbaar.

Ook Security.nl lijkt hier uit te zijn op click-bait; "misleidde"? Hoezo? Dat is wel erg zwaar aangedikt. In de betreffende blogpost staat het woord misleiding niet. Een artikel voor programmeurs, wellicht niet met achteraf bezien volledig juist (wat dat dan ook is "juist") advies? Als dat al "misleiding" is .... pfff...

Ik geef de hele dag advies. Dat is mijn vak. Daar zit ook vast wel eens ruis in. Is dat misleiding? Kom op zeg!

Ik herhaal nog eens iets wat ik hier al eerder stelde... Elke post op dit forum die een stammensttrijd teweeg brengt diskwalificeert voor mij de poster die die stammenstrijd start. Voor mij doe je dan even niet meer mee. En door dit fenomeen hoor ik om mij heen ook steeds meer dat mensen in het security veld om deze reden ook security.nl minder serieus nemen. Erg jammer.

http://www.gnu.org/software/libc/manual/html_node/crypt.html https://stackoverflow.com/questions/2179649/are-passwords-on-modern-unix-linux-systems-still-limited-to-8-characters combineer dat eens met het gangbare share van accounts en afhouden van gebruik van meer groepen dan 16.
http://www.linuxquestions.org/questions/linux-general-1/overcoming-sys_auth-16-group-limit-when-mounting-a-netapp-nfs-export-4175547310/.
Doe dat in een pam aware tool met gebruikers in een big data setting en je hebt een uitdaging waar de informatieveiligheid niet meer te doen valt wegens alle weerstand want te moeilijk en te complex. De vlucht naar een ad koppeling en Windows aanpak is gangbaar.


Zoek eens op Meos Backend ict politie avp. Ik zag daartussen een heel ict verslag op hoog niveau maar met her en der technische details. Verwijderen Oracle directory services inzetten ad met I am en nog veel meer aardige zaken.

De systemen Windows, Apple (Android) en Linux hebben allemaal hun voor en nadelen en eigenaardigheden.
Je kiest voor een omgeving omdat je die prettig vind werken en/of omdat de hard/software die je gebruikt daar beschikbaar is.
Het afzeiken van een ander systeem is een soort van nationale sport geworden zonder winnaars.

Linux vroeger: https://en.wikipedia.org/wiki/Crypt_(C)#Traditional_DES-based_scheme
Windows vroeger: https://en.wikipedia.org/wiki/LAN_Manager#Cryptanalysis

Ik ga niet zeggen welke van deze twee methoden ik het beste vind, maar heb daar wel een mening over.

Ik heb geen precieze tijdlijn paraat, maar de crypt-functie in Linux-distro's is al vele jaren in staat om sterkere hashes te gebruiken. De huidige versie in Debian ondersteunt ook MD5 (wat je natuurlijk ook niet meer moet gebruiken), SHA256 en SHA512. De laatste is de default voor nieuwe wachtwoorden.
Dat is alleen van toepassing op de DES-variant. Ik vraag me af of ik nog heb meegemaakt dat die werd gebruikt. Ik ben voor het eerst in 1997 met Linux gaan werken, als ik me niet vergis.
http://nfsworld.blogspot.nl/2005/03/whats-deal-on-16-group-id-limitation.html:

Het lijkt erop dat je gemakzuchtig wat zwaar achterhaalde informatie bij elkaar zoekt op het web en daar gewichtig mee doet. Dit zijn geen voorbeelden die uitleggen dat je iets op een verkeerde manier moet gebruiken, het zijn voorbeelden van beperkingen die in hedendaagse versies van de software achterhaald zijn.

Maar maak jij je niet aan net zoiets schuldig, Neb? Het is niet fraai als Microsoft zwaar achterhaalde informatie op zijn website laat staan, maar om nou te gaan doen alsof dat representatief is voor het kennisniveau van Microsoft vind ik te kort door de bocht, binnen dat bedrijf is echt wel meer kennis aanwezig.

Dat wil niet zeggen dat ik vind dat ze het altijd goed gepresenteerd en toegepast hebben. Een voorbeeld uit eigen ervaring, dat hopelijk ook zwaar verouderd is ;-).

Ik heb ruim tien jaar geleden een tijdje meegewerkt aan een webapplicatie die in ASP.NET werd ontwikkeld. Daar kreeg ik te maken met onder meer het gebruik van vesleutelde cookies door het ASP.NET-framework. Ik vraag me bij zoiets af hoe ze die versleuteling dan regelen, en ik heb me suf gezocht in de toenmalige documentatie en er geen woord over gevonden. Ik geloof dat MSDN nu een stuk gestructureerder is, maar toen was het voor een groot deel een netwerk van naar elkaar linkende artikeltjes met voorbeeldjes van hoe je zus kan doen en hoe je zo kan doen, met een slechte index erop waardoor je nooit wist of je alles al gehad had of net dat brokje informatie wat je zocht had gemist, en waar uitleg over dingen waar niemand een leuk how-to-verhaaltje over had geschreven soms onmogelijk in terug te vinden was.

Ik heb toen mijn antwoord geforceerd door zo'n versleutelde cookie in een request door troep te vervangen, waarop de betreffende encryptie-library crashte. Aan de crash kon ik zien in welke libraryfunctie het werd afgehandeld, en aan de naam daarvan welk algoritme werd gebruikt. Dat was op zich een prima algoritme, alleen bleef het abracadabra waar dan de gebruikte sleutel vandaan kwam en of het wel op een goede manier werd toegepast.

Mijn klacht toen was niet dat de implementatie niet deugde, maar dat ik er geen documentatie over kon vinden waarmee ik dat enigzins kon beoordelen. De documentatie toen leek op overstappende VB-programmeurs gericht te zijn, die in die tijd hevig afgaven op hoe moeilijk (toen nog) Sun de Java-documentatie had opgezet; de grootste klacht was dat Sun conceptuele verhalen schreef met veel te weinig codevoorbeelden. En dat was grappig genoeg documentatie waarin ik antwoorden op dit soort vragen moeiteloos wist terug te vinden, en als ik de concepten snapte had ik geen codevoorbeelden meer nodig. Mijn conclusie was dat Microsoft zich op een heel ander slag programmeurs richtte dan Sun. Sun richtte zich op mensen die op een conceptueel niveau wilden snappen waar ze mee bezig waren; Microsoft richtte zich op mensen die niet lastig wilden worden gevallen met diepgaand begrip maar een voorbeeldje wilden kopiëren dat werkte zonder er al te diep over na te hoeven denken.

Als ik verder in de tijd kijk naar Microsoft's documentatie, van voor de .NET-tijd, eind jaren '90 heb ik het dan over, dan verwezen de webpagina's veelvuldig naar allerlei Word-documenten die door Microsoft-medewerkers over diverse onderwerpen waren geschreven. Ik kan me bijvoorbeeld herinneren dat dat was waar ik op uitkwam toen ik threadingmodellen van Windows probeerde te doorgronden. Ik vond in een behoorlijk ongestructureerd geheel twee Word-documenten die duidelijk leken, een over die modellen in het algemeen en een over hoe IIS ze toepaste, en IIS leek volgens dat tweede document dingen te doen die volgens het eerste niet mogelijk waren. Als ik het artikel waar Ned naar linkte lees dan krijg ik de indruk dat het wel eens een restant uit die tijd kan zijn geweest dat domweg aan alle opruimacties ontsnapt is. Niet fraai, maar zoiets kan gebeuren.

Nooit gedacht dat hier goed geformuleerde volwassen posts waren.
Je hebt mijn blik op de gemiddelde bezoeker opgekrikt, thanks :]

TL;DR: What (s)he said.

Het is die verouderde dedocumentatie waar nog steeds mee geschermd wordt door linux beheerders architecten om iets niet te doen. Praktijkervaring.. dat de informatie fout en misleidend is weet ik, ik heb er gewoon last van. Enig idee met wat voor gevoelige gegevens er in de bi big data setting gewerkt wordt? Zeer frustrerend als je weet dat het beter kan maar zo teniet gedaan wordt.

Voor .net was er in oudere versies een secùrity invulling. De argumentatie was dat de gangbare secùrity beheerders te veel dwarsliggen en dat er daarom iets nieuws nodig was. Dat de is er intussen uitgehaald. Java heeft ook zoiets ingebouwd remt het argument een oplossing te zijn in c/s omgevingen. Je wordt er niet vrolijk van als je de impact doorkrijgt.
Allemaal praktijk en uitgezocht omdat het opspeelde.

Nee het is helaas niet echt opgelost integendeel het is veel makkelijker naar anderen te wijzen. Ach ik houd er werk aan over als het echt eenvoudig was kon je het met minder mensen ad en had je mind er vaardigheden nodig.

Volgens mij is dat al een tijdje zo, en dan des te meer op posts zoals deze, die ook best een stuk neutraler geformuleerd hadden kunnen worden.

Omdat er van verschillende kanten precies daarop aangestuurd werd.

Ondertussen, ja.

De EFF had al een mooi project in 1997 met hun "DES cracker", en vergelijk de prestaties en kosten van dat ding met, zeg, wat machines volgepropt met GPUs. Dat is de makkelijke optie; ondertussen hebben FPGAs ook niet stil gestaan, en is zelfs ASICs bakken makkelijker geworden. DES kraken heeft net als crypto minen heel weinig IPC nodig en schaalt dus vrijwel linear met de hardware. Plus dat met verschillende truuks iets van 14 van de 56 bits van de sleutel terug te vinden zijn, dus je hebt effectief maar 42 bits aan sleutel.

Dan nog zijn er betere alternatieven. DES, zeker in enkelvoudige vorm, is gewoon dood en begraven en dus niet meer bruikbaar. Wellicht een beetje zoals de vonkgenerator ondertussen terecht verboden is; het werkt wel maar het is gewoon geen goed idee om het nog te doen.

Dit is niet door de Redactie neergezet, maar door Neb Poorten. En ja, de post hier was zoals dat heet "flamebait".

Als je beter hoort te weten dan wel ja.

Plus degenen die zelf ook even vol op het bash-orgel gaan (onderwijl klagend dat alle anderen zo bashen, natuurlijk).

Ach ja, je moet security.nl een beetje op waarde weten te schatten. Ze typen persberichtjes over en vaak van erg lage qualiteit, maar zo gek veel beter is er niet te vinden in het wereldje. Om die en andere redenen neem ik de hele computer security cottage industry al een tijdje niet meer serieus.

Als het echt beter moet, moet het gewoon echt anders. Tot die tijd is "computer security" een consultancy als alle andere. "If you're not part of the solution, there's good money to be made prolonging the problem."