Mac OS X laat wachtwoorden in plain text rondslingeren

Heise.de meldt dat Apples nieuwste besturingssysteem, Mac OS X, bepaalde wachtwoorden in tekstvorm bijhoudt. In de swapfiles in /var/vm is het wachtwoord van de ingelogde gebruiker namelijk gewoon in plain text te lezen, aldus Heise. Dit brengt belangrijke risico's met zich mee wanneer kwaadwilligen via virussen of trojan horses toegang tot dit bestand krijgen. Dit veiligheidsrisico is overigens ook de reden dat wachtwoorden normaal gecodeerd opgeslagen worden en met behulp van een hash-waarde gecontroleerd worden als ze opgevraagd worden. Het probleem zou zich dan ook enkel bij Mac OS X voordoen en niet optreden in Linux.

Het lek is echter niet zo eenvoudig te misbruiken als op het eerste zicht lijkt, zo blijkt als we dit uittesten. Zo hebben gewone gebruikers standaard geen toegang tot deze, overigens binaire, swapfile. Men moet dus eerst root-toegang hebben om het bestand te kunnen lezen. Als een programma echter onder de root-gebruiker draait, dan blijkt het inderdaad mogelijk te zijn het wachtwoord van de ingelogde gebruiker uit deze swapfile te herleiden. Het werken met root-toegang wordt echter altijd afgeraden en is onder Mac OS X zelfs niet eenvoudig te realiseren, zodat het risico beperkt blijft. Desondanks blijft het opvallend dat het besturingssysteem op deze manier met de wachtwoorden omgaat.

Een applicatie met root-toegang kan het wachtwoord uit het swap-bestand uitlezen

Reacties (109)

[ebes]

Het artikel mist de kern van de zaak. Natuurlijk kun je als root de meest onfrisse dingen op een systeem doen, dus ook wachtwoorden vinden.

De onderliggende discussie over het opslaan van wachtwoorden in cleartext, one-way-hash of two-way-hash is al zo oud als de weg naar rome.

One-way-hash (is met een bekend algorithme zonder decryptie-methode versleutelen) is weliswaar het meest veilig, maar ook het meest onbruikbaar. Probeer voor de gein eens tig-duizend gebruikers met one-way hashed wachtwoorden naar een ander systeem te verhuizen. Kan dus niet zonder vieze truuks op root-niveau uit te halen, en daarmee zijn er goede redenen om niet alles tot in het oneindige te encrypten. Het moet ook gewoon beheerbaar zijn.

Wat *wel* een vervelend gat is dat je met hetzelfde wachtwoord ook je filevault kunt openen, iets wat je als root normaliter niet zomaar kunt. (Filevault onder OSX is de mogelijkheid om je home directory in zijn geheel als blob te encrypten, zodat je er alleen met je eigen wachtwoord transparant bij kunt). Aan de andere kant: als je root rechten hebt, zijn er allerlei middelen om achter het gebruikerswachtwoord te komen, dus een echt nieuw gat is het ook weer niet.

Beetje sensatieverhaal, wat mij betreft. Goed van Youri om het meteen even te proberen. Ik heb hier op dit moment 4 swapfiles met in totaal 1GB swapped data staan, en mijn wachtwoord staat er niet in... (1Gb? WtF? Maar eens wat beheugen bijprikken...)

[Anoniem: 32767]

One way hashing met wachtwoord zoals boompje kerver of naam van je vriendin is nou niet echt bepaald erg veilig te noemen.

Snap ook niet waarom ze niet aan salting doen.

[P.i.R.h.o.]

Salting wordt gebruikt om te voorkomen dat twee mensen die hetzelfde wachtwoord gebruiken dezelfde hashcode hebben staan in /etc/shadow

Hoe: een timestamp mee wordt gehashed en daarna aan de hash wordt toegevoegd in binaire vorm. De kans dat op identiek hetzelfde moment twee gebruikers hun wachtwoord op hetzelfde wachtwoord instellen is zeer klein.

[Anoniem: 51487]

ik heb alleen vrienden

[Anoniem: 51487]

Wauw, als root kan ik een wachtwoord van een gebruiker vinden, als root kan ik deze ook wijzigen zonder dat ik het wachtwoord ken, dus als ik een user account wil hebben kan ik gewoon het wachtwoord wijzigen.

Natuurlijk is het ook handig om wachtwoorden uit de pagefile te halen om ze eens ergens anders te proberen

[Sprite_tm]

Het verhaal is inderdaad een beetje vanuit de Windows-kant bekeken: Zodra het uberhaupt mogelijk is is het eng. Het echte probleem is hoe iemand root-rechten kan krijgen, en dat zit op OSX wel vrij veilig.

Het artikel gaat dan ook over een non-issue: zodra een derde root-toegang op wat voor systeem dan ook krijgt moet je je wachtwoorden etc als compromised beschouwen: als ze het wachtwoord niet uit de swap kunnen vissen kunnen ze login/pam wel trojannen, een keylogger installeren of iets willekeurigs anders doen.

Er is hier maar 1, universele les uit te leren: Als een [h/cr]acker met rootrechten toegang heeft gehad tot het systeem is het enige wat je kan doen je systeem trashen en opnieuw installeren en je wachtwoorden veranderen. Alles wat iets te maken gehad kan hebben met de gekraakte installatie kan namelijk gelezen of gewijzigd zijn.

[Anoniem: 25844]

Superhacker Mitnick test hackbestendigheid OS X
07-12-2004 (bron: macfreak.nl)

Uit een onderzoek van de Amerikaanse krant USAToday en internetbeveiligingsbedrijf Avantgarde uit San Fransisco blijkt dat surfen met een onbeschermde internetverbinding vragen is om problemen.

De wereldberoemde hacker Kevin Mitnick, in 1995 gearresteerd wegens het hacken van één van Amerika's "best beveiligde computersystemen" en inmiddels zelf een veel gevraagde computerbeveiligingsconsultant, was door de krant gevraagd om samen met collega-consultant Ryan Russell een experiment uit te voeren. Het duo nam zes computers met verschillende besturingssystemen, waaronder ook een Apple Macintosh met Mac OS X, en sloot die aan op het internet zonder verdere beveiliging. De computers werden vervolgens twee weken in de gaten gehouden.

Een computer met Windows XP Service Pack 1 was binnen vier minuten gehackt, en telde na twee weken negen succesvolle inbraakpogingen. In een computer met Windows Small Business Server als besturingssysteem werd eenmaal ingebroken in die twee weken. De computers met Windows XP SP2, Windows XP met ZoneAlarm en een Linspire Linuxmachine, werden wel aangevallen maar niet gehackt.

Ook de MacOS X machine zonder ingeschakelde firewall werd niet gehackt in die twee weken tijd, ondanks bijna 140.000 aanvallen (ruim 8.000 per dag)!

Lees het hele artikel hier: USAToday:

http://www.usatoday.com/tech/news/computersecurity/hacking/2004-11-29- honeypot_x.htm

[TukkerTweaker]

Leuk sensatie verhaal maar ik geloof niet dat een niet ge-DNSde computer met willekeurig ip zoveel hackpogingen te verduren krijgt. Als ik namelijk de logs van mijn firewall bekijk blijkt er gemiddeld eens in de week een keer een exploit geprobeerd is te misbruiken.

[Hodgesaargh]

Heb ergens een Windows 2K en een 2K3 Server aan het net hangen en je wil niet weten hoevaak je "pogingen" tegenkomt. Nou vind ik een directory traversal attack niet echt een poging meer, maar als je dat meetelt heb je idd aardig wat "hackpogingen"

Waarbij ik het overigs raar vind dat Mitnick een Superhacker wordt genoemd... z'n specialiteit was social engineering. Zeg niet dat 'ie nix kon, maar om 'em dan superhacker te noemen gaat wat ver...

[chrisboers]

Leuk artikel, maar met welk programma monitoren ze die attacks? Ben wel es benieuwd hoeveel attacks mijn PC te verwerken heeft.

[Anoniem: 120782]

Geef meteen toe dat ik ook niet alles van netwerkbeveiliging afweet, maar 8.000 aanvallen per dag is wel veel. Ik zou zo gokken dat dat vaste ip-adressen waren (breedband). En waarom geven ze niet even een simpele definitie van een aanval? Kijk, een portscan kom bij mij ook tig keer per dag langs, zelfs van @Home, maar dat noem IK geen aanval. Dus ik vraag me af wat dan wel hun definitie van een aanval is.

[Anoniem: 25844]

ik weet niet of het zo is, maar wellicht hebben ze vantevoren aangegeven dat ze met dit onderzoek bezig waren en uitgenodigd om een poging te doen het systeem te hacken vantevoren aangekondigd zeg maar?

chris

overigens, ik denk dat osx, van nature een unix kernel, zoiezo heel erg veilig is. Microsoft is op de goede weg om Windows stukje bij beetje dicht te timmeren, met hun nieuwe service pack. Maar ze zijn er nog lang niet.

[Anoniem: 32767]

Conclusie Windows XP SP 2 en MacOS zijn even veilig?

En Windows SBS vergelijken met MacOS X is een vrachtwagen vergelijken met een ford ka...

[Onno]

Als je root bent op een machine kun je een wachtwoord sowieso wel achterhalen, niet alleen in OS X. Gewoon het geheugen in de gaten houden op het juiste moment en je hebt iemands wachtwoord. Even een breakpointje zetten in ssh op de plek waar een wachtwoord net gelezen is maar nog niet gehasht, enz.

Dat dit nou toevallig in het swapbestand belandt is niet zo netjes, maar maakt alleen wat uit als je geen root bent maar de hd wilt gaan stelen om 'm daarna te analyseren ofzo.

[serkoon]

Met privilege seperation gaat je wachtwoord zelfs plaintext over een pipe heen, zodat een strace/truss/whatever al genoeg is om passwords te zien (en hoef je dus niet meer moelijk te doen met ptracen). Handig he?

[Mijzelf]

Mac OS X laat wachtwoorden in plain text rondslingeren

OK, ze slingeren rond, maar wel op 7200 toeren of zo. Dat maakt het toch moeilijk te lezen, niet?

[Metal Baron]

Onzin, ik ben al 1 1/2 jaar OSX systeembeheerder en ben nog nooit als root ingelogd. Met een simpele sudo in de terminal kan je alles wat je wilt en ben je maar 5 minuutjes root, en zelfs dat is maar sporadisch nodig.

Iedere zichzelf respecterende systeembeheerder zal de woorden 'telnet' en 'root' nooit in 1 zin durven gebruiken.

[Eric Oud Ammerveld]

Dus jij hebt bij deze geen respect voor jezelf?
(Ik had er een EOL tussen gezet )

[LuCarD]

Kan je met sudo wel bij het bestand?

[egeltje]

Nee hoor, als goed beheerder log je als user in. OS X vraagt om je root password als je een actie wilt doen waar je root access voor nodig hebt. Dan doe je een sudo voor die specifieke actie.

Telnet en zelfs SSH staan standaard uit, dus die moet je ook al expliciet aangezet hebben.

Net als bij Windows is ook hier de veiligheid van het systeem zo goed als zijn administrator.

[Anoniem: 2072]

Telnet? Waarom verander je niet meteen de UID van elke user naar 0

[sid3windr]

als je ondertussen je telnet-poort hebt openstaan...
èn er een telnetd op hebt draaien...
èn iemand anders je root password kent...

dat bedoel je toch? en putty komt waar juist bij kijken?

onzin dus. Je moet al root hebben voor je zoiets kan, en dan is het wel een heel dwaze issue.

[serkoon]

Sjah. en als je sshd, login of whatever backdoored (en dat kun je als root), dan lees je zo alle passwords.

Het enige wat er blijkbaar vergeten is, is om een buffertje waar een password in opgeslagen is, op te schonen na gebruik of het buffertje expres niet te laten swappen.. Niet echt spannend, dus..

[Anoniem: 32767]

Is maar net wat je niet spannend vind. Ik wil niet dat root gebruikers mijn wachtwoord kunnen lezen!

Root exploit is al erg genoeg, en als je er dan ook nog wachtwoorden mee kan opslaan van iedereen die het systeem ooit gebruikt...

[serkoon]

Als je niet wil dat root je password kan lezen, moet je niet inloggen.

Als iemand root heeft, heeftie ook jouw password, als je inlogt tenminste. Als je niet inlogt, komt je password ook niet in swap en kan het ook niet op andere manieren gelezen worden (nahjah, bruteforce kraken van de MD5-hash). De in het artikel beschreven 'feature' kan dus ook niet gebruikt worden om van alle users een password te lezen zonder dat ze dat ooit ingetypt hebben..

[Anoniem: 32767]

Admins hier (windows en netware) kunnen echt niet de wachtwoorden van de gebruikers lezen.. dat vinden de users en admins wel zo fijn trouwens..

[arjankoole]

je kan onder unix ook niet de passwords lezen, alleen kun je wel als root su - <user> doen, en die user worden, niets bijzonders.

wat 't probleem van admins en users is dat admins de wachtwoorden weten van gebruikers snap ik niet, admins kunnen sowieso alles, inclusief een ieders meel lezen.

[serkoon]

Totdat een user met z'n password (dus niet een hash daarvan) inlogt op een systeem, dan kunnen admins het wel lezen. En dat was het punt.

Een root-user kan alles op een lokaal systeem (tenzij je met securelevels gaat werken, maar eigenlijk zelfs dan nog), dus ook passwords van users afvangen wanneer ze inloggen.

[Anoniem: 32767]

Hoeft niet hoor, kwestie van rechten zetten.

[SirBlade]

lophtcrack...

en social engineering werkt helaas ook nog maar al te goed. Als ik een gebruiker bel en om het wachtwoord vraag krijg ik het in 95% van de gevallen, ook al zijn de gebruikers gewaarschuwd nooit hun wachtwoorden af te geven.

[Anoniem: 61096]

Admins kunnen de wachtwoorden van gebruikers veranderen als de gebruiker zijn wachtwoord vergeten is, maar gelukkig niet zien wat jou wachtwoord was.

Dit met name omdat nogal wat gebruikers dezelfde wachtwoorden gebruiken voor meerdere systemen. Dus de admin van je ISP weet je wachtwoord niet en kan dus niet met jou credentials inloggen op je favoriete pornosite (of bedrijfsnetwerk of....) Het feit dat iemand Admin rechten heeft op 1 systeem wil niet zeggen dat hij die ook heeft op alle systemen waar je mee werkt.

[mxcreep]

@Philip Wagenaar
Leuk dat je niet wil dat root jou password kan lezen, maar wat schiet je ermee op, als root kan ik toch aan al jou files komen...mijns inziens een domme opmerking...

[Anoniem: 63780]

Misschien dat het wachtwoord dat hij op werk gebruikt ook werkt op zijn eigen systemen thuis bijv?

[Jack Flushell]

Sjah. en als je sshd, login of whatever backdoored (en dat kun je als root), dan lees je zo alle passwords.

Waaaahhaha
Jij snapt iets fundamenteels niet. Het root account is het _enige_ accout waarmee je alles moet kunnen als het systeem / een gebuiker op zijn bek gaat. Natuurlijk moet je als root dan recht hebben op die gegevens. Als bijvoorbeeld een harddisk eruit moet, moet hij als systeembeheerder (=root) toch jouw gegevens kunnen verplaatsen (en dus lezen). De root is de eigenaar / baas van de machine, die _moet_ alles kunnen!

Als je wilt dat de root je password niet kan lezen moet je niet inloggen.

[mxcreep]

En als je niet inlogd weet root vaak nog je password, aangezien hij je als user aangemaakt heeft naar alle waarschijnlijkheid
In elk geval kan ie em zo aanpassen...

[Anoniem: 80577]

als je sshd al hebt gebackdoored moet je niet eens de moeite doen om het passwoord gaan te lezen.
Dit is een erge fout maar je kan er enkel niet zomaar aan.
Standaard is de root account niet eens geactiveerd bij MacOSX. Dat moet de user zelf nog doen en de meeste Mac gebruikers kenne dat niet eens

[Anoniem: 63780]

Het root account is wel geactiveerd (wordt immers gebruikt voor alle services) maar door het ontbreken van een wachtwoord kan je zelf er niet direct mee inloggen totdat je een wachtwoord insteld:

# sudo passwd root

Ik hoop dat hier snel een patch voor komt, want dit foutje zit me ook niet zo 100% lekker.

[Anoniem: 31444]

Dus is hij niet geactiveerd. Als je onder UNIX bepaalde accounts uitzet, kan je nog wel applicaties draaien onder zijn naam. Moet maar eens voor de gein `sudo -u cyrus -s` draaien op je Appel-kist. Tada. Opeens ben je de user cyrus met apps draaiend onder zijn naam.

[Anoniem: 130161]

En iedereen zit altijd zo te ***** over Windows security

[boesOne]

Het werken met root-toegang wordt echter altijd afgeraden en is onder Mac OS X zelfs niet eenvoudig te realiseren, zodat het risico beperkt blijft

Daarom zit iedereen altijd zo te zeuren ..

[Grrrrrene]

En wat is je argument dan? Windows raadt je ook af om als admin in te loggen, maar gewoon een eigen useraccount aan te maken. Dat vind ik eerlijk gezegd geen argument. Dit is gewoon slordig, maar aangezien het nu eens niet over microsoft gaat, wordt er heel wat rustiger op gereageerd

[MetalStef]

Het verschil tussen Mac OS X en Windows XP is dat je bij OS X moeite moet doen om met root-toegang te werken en dat XP je bij XP standaard admin bent, ook al wordt dat afgeraden.

Sterker: Je moet aardig op de hoogte zijn van Windows om je admin rechten kwijt te raken!

[needless to say]

Een hoop programma's werken in Windows enkel met adminrechten. Dat er daar eerst werk van gemaakt wordt, dan wil ik best niet meer als admin inloggen in xp.

[Anoniem: 95032]

Inderdaad ik heb dit weekend XP geinstalleerd op mijn mac via VPC en ik had onmiddelijk een admin account. Er werdt mij helemaal niet gevraagd om een user account aan te maken. XP staat dus bij mij nog steeds in root. Doet er voor mij trouwens niet toe, want de keren dat ik xp zal gebruiken per jaar zal je op één hand kunnen tellen.

Dus wie beweert dat XP je aanraad om een user account aan te maken : Bogus!!!!

[Gé Brander]

Dus wie beweert dat XP je aanraad om een user account aan te maken : Bogus!!!!

Dat beweert niemand hier, er wordt alleen gezegd dat het afgeraden wordt. Door wat of wie staat er niet bij. Het lijkt mierenneuken, maar zo komen wel de misverstanden in de wereld.

[boesOne]

Dat je ze vervolgens met admin rechten laat werken is natuurlijk je eigen fout en mag je IMO XP niet aanrekenen.

Dat de default rechtenset van die user de admin rechten zijn, en dat een 'niet al te slimme' default instelling is, mag je XP niet aanrekenen ?

Dat er pre SP2 een firewall bijgeleverd was die default uit stond mag je XP zeker ook niet aanrekenen..

Dat pre SP2 activeX objects zo'n beetje toegang hadden tot t hele systeem, mag je XP zeker ook niet aanrekenen...

De pre SP2 XP is out of the box qua security een ramp...

[Duinkonijn]

@ Wim-Bart

Nou gewoon met bepaalde programma`s kijken als wise wat een programma voor resources vraagt..

vervolgens met een GPO in je AD openstellen...

klaaar

[hr]

over XP de eerste user is admin...
de resterende zijn gewoon users naar mijn mening

[ppl]

@ Wim-Bart

In bedrijven mogen gebruikers niets installeren en veranderen. Wil je dat wel dan moet je maar een verzoek indienen. Het zou een chaos worden als dit niet zo was.

Virusscanners en andere zaken zullen ze wel een speciale versie van gebruiken die ze in het netwerk kunnen managen op 1 centrale plek. Die pakketten zijn wel berekend op het feit dat ze moeten draaien onder beperkte rechten.

Daarom is Norton Antivirus ook zo vaag, voor het installeren van de updates moet je admin rechten hebben, maar bij de bedrijfsversie (Symantec Antivirus) kan dat gewoon wanneer je een normale user bent.

@ duinkonijn

Ja, bij de setup is het eerst ingevulde account een administrator en alle accounts die volgen zijn gewone users. Maak je achteraf in XP nog wat user accounts aan dan gebruikt xp de standaard setting en die staat op admin rechten. M.a.w. dan krijgen alle accounts die je dan toevoegt standaard admin rechten. XP is zelf dus zo inconsistent als maar mogelijk.

Daarnaast is het allemaal wel leuk en aardig om te draaien als normale gebruiker maar in Windows is dat nagenoeg onmogelijk en op unix/linux/mac platform weer wel. Je kunt in Windows dan wel runas gebruiken maar dat werkt ALLEEN voor .exe files. Leuk als het tegenwoordig veelal msi is....

[Anoniem: 88138]

D00000ds! Denk eens na. Waarom zou het niet plaintext op een gegeven moment in de swapfile staan? Stel je hebt een machine met weinig geheugen. Op het moment dat jij veel programma's open hebt staan (en dus veel geheugen in gebruik hebt) en ergens een wachtwoord moet intikken, moet het wachtwoord *ooit* unencrypted in het geheugen terechtkomen, immers om het te encrypten heb je *ook* geheugen nodig. Als dat dan toevallig net weggeswapped wordt naar disk, ja, dan staat je password voor onbepaalde tijd te lezen, maar *enkel* voor de root user (die jouw password sowiezo niet nodig heeft). Zo werkt het op de meeste unices hoor. Ook ik heb op dit moment 2 swapfiles van 68 MB, maar mijn password staat er echt niet in... Als root kun je wel op meerdere manieren iemands password lezen.

[Jack Flushell]

Standaard kan je meerdere gebruikers aanmaken onder XP. Dit gebeurd _altijd_ bij de installatie. Het is onzin dat je zegt dat dit niet zo is. De eerste gebruiker die je aanmaakt is admin en de rest zijn normal users, hierom wordt _altijd_ gevraagd bij de installatie van XP (zo'n schermpje met 1,2 3 etc.) Ik denk dat je hebt liggen slapen ofzo.

Ik moet wel zeggen dat het niet echt duidelijk is bij installatie dat het niet zo veilig is het eerste account te gebruiken daar dit de admin is.

[Anoniem: 116394]

Ja, werken onder Windows is wel mogelijk zonder Admin rechten, maar veel applicaties kunnen hier zo slecht mee omgaan, dat je wel als admin op je systeem moet werken. Er zijn zelfs onderdelen van het besturingssysteem die slecht hiermee overweg gaan.

Klein voorbeeldje: probeer maar eens door de kalender heen te bladeren in de 'eigenschappen voor datum en tijd' (als je in de systemtray op de tijd dubbelklikt). Zonder admin rechten (win2k iig) mag je de kalender niet bekijken, want je mag de datum niet veranderen als je geen admin bent.

Ik had vanwege veiligheidsoverwegingen ervoor gekozen om als standaard gebruiker op mijn pc te werken, en alleen voor installaties etc als admin in te loggen, maar na weken frustratie heb ik mijn 'normale' account ook admin rechten moeten geven, omdat virusscanner en zelfs simpele applicaties foutmeldingen gaven.

De meeste frustraties kwamen overigens van niet MS applicaties btw. Verder ben ik wel fan van Windows hoor

[Beaves]

Inderdaad ik heb dit weekend XP geinstalleerd op mijn mac via VPC en ik had onmiddelijk een admin account. Er werdt mij helemaal niet gevraagd om een user account aan te maken.

Vreemd, de keren dat ik Windows XP installeerde moest ik wel een gebruiker aanmaken omdat Windows anders niet verder wilde met de installatie. Die account zie je dan weer terug in het inlogvenster van XP, waarbij er op dat scherm nergens de admin account te vinden is. Wil je daarmee inloggen moet je een aantal opties instellen.

Wat wel zo is, is dat de aangemaakte gebruiker Administrator rechten heeft en dat is niet de bedoeling.

[Glashelder]

XP maakt een account "administrator" aan met adminrechten, en voor de rest voor alle gebruikers een apart account. Volgens mij zijn dat power-users maar kan er naast zitten.

[Wim-Bart]

Ik had vanwege veiligheidsoverwegingen ervoor gekozen om als standaard gebruiker op mijn pc te werken, en alleen voor installaties etc als admin in te loggen, maar na weken frustratie heb ik mijn 'normale' account ook admin rechten moeten geven, omdat virusscanner en zelfs simpele applicaties foutmeldingen gaven.

Hoe doen bedrijven dat dan????????

[Grrrrrene]

@Glashelder

Dat bedoel ik ook: Als je XP installeert is het standaard admin account uitgeschakeld en wordt je gevraagd om aparte accounts aan te maken die niet eens gelijknamig aan admin of de naam van het admin account mogen zijn.

Dat je ze vervolgens met admin rechten laat werken is natuurlijk je eigen fout en mag je IMO XP niet aanrekenen.

Ik heb bij mijn ouders thuis bijvoorbeeld iedereen een gewoon useraccount gegeven en alle software met mijn eigen admin account geinstalleerd. Nooit geklaag over gehoord, ze kunnen alles wat ze willen kunnen.

[Dennizz]

meeste standaard programma's geven geen problemen...

Ik noem:
- Lotus Notes
- Novell
- Citrix (mits 1x ingelogd onder admin in de specifieke situatie in ons bedrijf)
- AS400
-Office

maar dit zijn pakketten die daar ook wel op ontwikkeld zijn imho...

Uitgaande van de situatie dat de gebruiker Power User is (Hoofdgebruiker) maar eigelijk kunnen ze dan al weer teveel op de PC. Een eigen gemaakte policy is ws. de beste uitkomst in alle gevallen.

zodra je als thuisgebruiker allemaal kleine programmatjes gaat gebruiken voor allerlei lossen doeleinden ipv complete suites die ontworpen zijn voor bedrijven loop je meestal tegen problemen aan. Maar misschien dat een aangepaste policy ook hier veel kan doen.

Conclusies zijn overigens getrokken uit een klein jaar ervaring aan support leveren op alle software binnen ons bedrijf waar zon 100 mensen hier mee werken.

[ppl]

Reply @ Denizz

Novell is een bedrijf en geen programma...
AS400 is een midrange server en geen programma...
Citrix is ook een bedrijf en geen programma...

Het is ook de grootst mogelijke flauwekul om "bedrijfsprogramma's" aan te raden...WTF zijn "bedrijfsprogramma's" in godsnaam dan?

Als jij een programma of driver als gebruiker met beperkte rechten (oftewel een "user" zoals windows het noemt) wilt installeren krijg je vrolijk de melding dat je daar niet genoeg rechten voor hebt. Dan kan ik Lotus Notes, Microsoft Office of wat dan ook installeren maar geen rechten daarvoor is helaas pindakaas.

Novell Netware met Zenworks for Desktops is een manier om dan te zorgen dat users dus wel een printer kunnen installeren of bepaalde stukken software. Dan wordt het naar de client gepushed en installeert niet de gebruiker het stuk software maar Zenworks. Die kan het dus wel.
Pin me niet vast op de exacte werking van het verhaal want dat weet ik niet, zo goed is mijn Novell software kennis nou ook weer niet.

Het ligt dus aan het type account en niet aan het feit of je een losse thuisgebruikersprogramma of bedrijfsprogramma installeert.

In bedrijfsomgevingen blijft het ook maar de vraag of je uberhaupt wel wil hebben dat gebruikers applicaties kunnen installeren want het wordt een chaos en puinzooi om dat in beheer te krijgen/houden.

@ devzero
Erg fijn dat zo'n password dan in plain text wordt opgeslagen wanneer je niet voldoende geheugen hebt. Lijkt me toch wel enigzins een vorm van securitybreach, je zou ook gewoon het password niet op kunnen slaan.
Verder snap ik je reply ook niet zo want in het laatste stuk spreek je het voorgaande ineens helemaal tegen

[arjankoole]

onder XP werkt 't als volgt:

tijdens de install moet je een gebruiker opgeven die administrator rechten krijgt (dit wordt op een later moment overruled als je de machine in een windows domein hangt), in een thuis situatie of kleine office omgeving is die user administrator en kan alles, de andere gebruikers mogen wel/niet dingen aan de hand van de rechten die ze krijgen als de account wordt aangemaakt.

die Administrator account, waar je bij XP setup een wachtwoord voor moet geven, komt naar voren als de gebruiker(s) met administrator rechten gelocked zijn (3 keer het verkeerde wachtwoord bijvoorbeeld), zodat je er altijd nog in kan om de boel te fixen.

[stealth]

-

[Anoniem: 71455]

Heb je weleens van "uitvoeren als" gehoord, dan kun je zelf ingelogd blijven op een account met beperkte rechten, terwijl je voor het installeren of configureren tijdelijk adminrechten krijgt. Je hoeft daarvoor niet uit te loggen.

[Anoniem: 71455]

Dat kan, maar als Windows XP wordt geïnstalleerd bij een bedrijf, dan wordt dat niet door de gebruiker gedaan die het workstation gebruikt, maar door een systeem- of systeem/netwerkbeheerder. Deze weet maar al te goed dat alle accounts adminrechten hebben en zal er dus voor zorgen dat er alleen een adminaccount en accounts met beperkte rechten zijn. Op je eigen systeem is het je eigen risico.... als iemand niet weet dat er adminaccounts zijn en accounts met beperkte rechten, dan moet zo'n persoon gewoon niet werken met Windows NT. Hetzelfde princiipe gaat op voor andere besturingssystemen waar zowel gewone accounts als adminaccounts voor bestaan.

[dualspeed]

De veiligheid van jou systeem is niet de verantwoordelijkheid van de softwaremakers hoor! Dus deze opmerking slaat nergens op. Niemand verplicht je die software te gebruiken; het lijkt me aan jou om een signaal te geven aan de makers van dergelijke software, bijvoorbeeld door het niet meer te gebruiken.

[whoami]

devzero:
Je wachtwoord moet helemaal niet 'unencrypted' worden. Wat je doet als je een wachtwoord intikt: je encrypt het ingetikte wachtwoord met hetzelfde algoritme als jouw wachtwoord, en je vergelijkt die hash met de opgeslagen hash van jouw wachtwoord, en klaar is kees.

Wachtwoorden mogen nooit unencrypted opgeslagen worden, of in het geheugen staan. Zelfs de variablen die de berekende hashes bevatten, maak je best zo snel mogelijk weer leeg, dit om zelfs te voorkomen dat die ooit naar een swap file gedumped worden (al zijn ze encrypted).

[Wim-Bart]

Geldt dit ook niet voor Windows XP?

[Anoniem: 27537]

Tsja, Microsoft heeft hier bar weinig keus. Vroeger, toen er "nog geen netwerken waren" en we nog met Windows 95 werkten, bestond er nauwelijks beveiliging in Windows. In die tijd zijn tal van bedrijven hier gebruik van gaan maken door enorm slordig te programmeren. Met Windows 2000 en vervolgens XP heeft Microsoft enorm veel guidelines opgesteld over hoe programma's netjes behoren te functioneren (%windir% is dus niet de plaats voor je temp bestanden en in je %progdir% behoor je geen user configuration files te zetten). Helaas houden bar weinig bedrijven zich hieraan en heeft Microsoft ook nog eens een backward-compatability credo.
Apple gooit gewoon een geheel nieuw OS op de markt en verplicht iedereen alles om te gooien. Tsja. Dat had Microsoft ook kunnen doen maar ik ben bang dat men dat niet zonder meer had geaccepteerd.

Tip aan iedereen: schrijf je programma's voor Windows, houd je aan de guidelines. Werk je voor een bedrijf dat dat niet doet, laat dan niet na daarop te wijzen. En run als normal of power user. Klaag over ieder programma dat niet naar behoren functioneert. De enige manier waarop we ooit een veilige Windows krijgen is als we als consument met minder geen genoegen nemen. En ja, daarvoor zullen we moeite moeten doen.

* 786562 Bugu

[J2pc]

Ik heb nog nooit met mac OS gewerkt,

maar dit zal toch wel een behoorlijke 'Autsj' zijn voor Mac

Gelukkig zijn de virussen voor de Mac niet zo heel veel voorkomend. Waarschijnlijk zal Apple wel vlot met een patch komen (?)

Ook wel een beetje eigen schuld dikke bult natuurlijk, als je met root-rechten allerlei dingen gaat doen.
Dat 't in Windows nou voor zoveel dingen moet (zou een hoop schelen als 't niet hoefde)...

[Anoniem: 130161]

Ook wel een beetje eigen schuld dikke bult natuurlijk, als je met root-rechten allerlei dingen gaat doen...

Vind ik hier los van staan. Wachtwoorden horen gewoon niet zo (onversleuteld) bewaard te worden.

[Keypunchie]

Dit is wel ff iets anders dan RPC buffer overflow waardoor je willekeurige code kunt uitvoeren...

[hvlint]

Wat ik als mac gebruiker nu niet begrijp in dit verhaal is dat bij mij in elk geval standaard, zonder extra handelingen alle wachtwoorden versleuteld zijn met shadowhash en dus niet textbase

[Sfynx]

Vind ik hier los van staan. Wachtwoorden horen gewoon niet zo (onversleuteld) bewaard te worden.

Ik weet hiet hoe simpel dat te verhelpen is als je echt nooit een password unencrypted in RAM wilt hebben staan. Zelfs als je het meteen versleutelt nadat een gebruiker het ingetypt heeft, staat het even niet versleuteld in RAM. Er is dan een kans dat het weggeswapped wordt naar disk (al weet ik niet hoe het memory management van MacOS precies werkt). Misschien kan de tijd dat zoiets onnodig in RAM staat nu wel drastisch verkort worden, maar helemaal nooit lijkt me niet kunnen.

Verder kan naar ik lees alleen root erbij als er iets in de swap staat, en het lijkt me dat je sowieso niet op een machine gaat werken als je de beheerder niet vertrouwt. Die heeft die bug echt niet nodig om je passwords te weten te komen.

[tricksel]

Ik ben hier eens even aan het proberen geweest, en kan m'n eigen wachtwoord NIET terugvinden. Het zal misschien zo zijn dat men die kan terugvinden op het moment dat er een applicatie gebruik heeft gemaakt van de swapfile, waarbij het wachtwoord nodig was.

[ebes]

Je hebt toch wel grep -a gebruikt? Anders is'ie ook zo snel klaar...

[Eric Oud Ammerveld]

Kijk na het uitloggen dan eens in je .bash_historie
Wedden dat hij daar tussen staat.