artikel gelezen en:
- UAC wordt NIET omzeilt, het werkt gewoon.
- Het genoemde problem is dat er wat anders door UAC wordt uitgeveoerd dan de verwachting/bedoeling was. PISHING.

Je kan de verwachting/bedoeling alleen invullen door preceies te weten wat de bedoeling verwachting is. Niets bijzonders gaat voor elk te beheren onderdeel met elk OS op. Het is de kern van ITIL waarbij een change als probleem gezien wordt. Elke verandernig(!) en ook patch op elke machine ongeacht type impact wordt op die manier beblokkeerd.

Zover ik weet wordt UAC door heel veel mensen zelfs gewoon uitgezet, omdat het soms erg lastig is om een button extra aan te klikken. Pasop, ik hoor daar ook bij hé. Ik geloof niet dat UAC veel opbrengt, want het is van microsoft. Overigens faalt MSE ook als de pest, terwijl ik in het begin ook veel geloof had in MSE.

UAC wordt niet omzeild al wil je dat graag lezen. Letterlijk in de tekst vertaald: en origineel

Het staat er echt. De kern van het probleem is dat je niet goed weet waar je toestemming voor verleend. De klassieker als operationele instructie voor het process: tik y-y-y-y denk vooral niet na. De hamvraag is natuurlijk of je het ook echt weet wat de gevolgen zijn/ kunnen zijn bij een normale actie. Het gaat immers uit van het vertouwen dat hetgeen wat aangeboden goed is en niet slecht (malware). Dat is geldig voor alles (installeer die fix ...).
Hoe weet je dat?
Die "show details" is ook geen garantie, het maakt de onzekerheid enkel wat kleiner.
Ik verbaas me altijd over degenen die beweren: "ïk heb die en die fix geinstalleerd, dus ben ik veilig" De enige zekerheid is de onzekerheid.

Welles/nietes : Bedoeling versus Ontwerp

Het idee achter UAC is het tegenhouden van malware.
Naar aanleiding van dat idee is men aan de slag gegaan en daar is een bepaald ontwerp uitgekomen.
Dat ontwerp vraagt wel om een wachtwoord maar laat niet standaard zien voor welke processen het dat wachtwoord vraagt.
Om te zien voor welke processen je toestemming geeft moet je een extra handeling verrichten, namelijk de detailweergave handmatig aanklikken (elke keer weer).

Het ontwerp zal, hopelijk en nog al wiedes, werken zoals het ontworpen is; het laat iedere keer wanneer dat nodig is een UAC window zien waarbij je een beheerder wachtwoord moet invoeren maar geeft daarbij standaard de details niet weer.
Omdat vooralsnog het verhaal is dat dit UAC proces geen uitzonderingen kent en deze standaard procedure op dezelfde wijze herhaalt, werkt het zoals het ontworpen is.

De bedoeling was echter het verhogen van de veiligheid door het tegenhouden van malware.
In de vertaling naar het definitieve ontwerp is daar een hiaat ingeslopen, namelijk het feit dat de detailweergave niet standaard wordt weergegeven en dat het dus mogelijk is daarvan misbruik te maken.

Hoewel het ontwerp dus werkt zoals het ontworpen was, is de uitkomst van het ontwerp niet gelijk aan het doel.
Het doel was namelijk het tegenhouden van malware waarbij hierbij is aangetoond dat dat niet altijd lukt.
De reden waarom dat niet lukt is dat de vertaling van de bedoeling naar het ontwerp niet goed was omdat het de details van de processen die toestemming willen niet standaard laat zien.
Daar de praktische werking van UAC leidend is en niet het idee erachter, faalt de praktische uitwerking in de vorm van het ontwerp hier. Omdat het design/ontwerp, dus de werking van UAC in de praktijk kan worden gepasseerd.

Het idee achter UAC, namelijk het tegenhouden van malware zal dus opnieuw moeten worden bekeken en leiden tot een aanpassing van het ontwerp van UAC omdat UAC in de praktijk dus eenvoudig gepasseerd kan worden.

In de herhaling ; wat leidend is in de praktijk is het ontwerp en niet het virtuele idee erachter zoals het bedoeld was.
Met goede bedoelingen alleen redt je het niet in security.
As is verbrande turf.

Is maatregelen nemen tegen mogelijke phishing aanvallen teveel van het goede?
Hoewel je kan discussiëren over het feit hoever je moet gaan in het beschermen van gebruikers en in hoeverre dat realistisch of haalbaar is, zou een aanpassing van het ontwerp van UAC, in dit specifieke geval, een kleine moeite zijn om tegemoet te komen aan het security doel erachter opdat idee en praktijk weer samenvallen.

Vooralsnog wordt met het huidige UAC design de doelstelling achter UAC niet gehaald omdat het ontwerp in de praktijk niet goed is uitgewerkt.

UAC wordt gepasseerd met deze truc, UAC wordt omzeild.


Tip voor je, haal je tekst standaard door de spellingscontrole voordat je het plaatst. De terugkerende taalfouten zijn niet om aan te zien, gebruik van caps lock maakt het alleen nog maar dramatischer.
Hoewel het idee achter de spellingscontrole niet volmaakt is en soms toch nog wordt gepasseerd door weerbarstige foutjes die erdoor heen glippen (ik weet er alles van), haalt zij er meestal wel wat uit wat weer ten goede komt aan de leesbaarheid.
Een dergelijke kleine vooruitgang zou voor een UAC niet acceptabel zijn, voor een spellingscontrole is een dergelijke geen 100% score toch winst, het vergroot immers de leesbaarheid van je reacties en verkleint de kans dat mensen mogelijk vroegtijdig afhaken.

Ik zocht op duckduckgo of er geen open source programma is die UAC kan vervangen, ik kwam meteen op deze: http://www.replaceuac.com/

Iemand daar ervaring mee?

Veel mensen werken thuis nog 'gewoon' met een administrator account....

Het ontwerp is netjes gedocumenteerd , zie: http://en.wikipedia.org/wiki/User_Account_Control.
Op het OS niveau praat je dan over privilged identity management. Het probleem van gebruiksvriendelijkheid versus beheersbaarheid is als zeer oud.
Ik verbaas me over het gebrek aan inzicht en wil om de zaken goed na te gaan en goed te regelen in deze tijd met allerlei zoekmachines.

Het probleem dat de gewone gebruikers het verschil niet willen maken in dat soort benaderingen tussen administrator en user processen leidt tot compromissen. In dit geval een popup. Ik heb hele postings gezien van gebruikers die dat schakelen tussen de administrator en user mode verfoeiden omdat het toch hun machine was. Daarbij beriepen ze zich op hun IT vaardigheden en kennis.

Een tip naar de andere kant: We zijn kennelijk zo druk met eigen standpunten en meningen (bashen) , dat het echt doel niet gehaald wordt. Nog erger het wordt gezien als een wereldje van nerds. Als je naar een veilige omgeving wilt moeten de leken (beslissers/managers) en gebruikers ook het nut zien. Daarbij het ook begrijpen waarom je iets doet of niet doet.

Overigens: Er staan bij mij best syntaxcheckers aan. Die zijn dusdanig eigenzinnig dat ze er constant andere woorden van maken. Goed dan hebben we over een design en implementatie fout waar we het over eens kunnen zijn.

Zoals wel vaker negeer je kritiek als blijkt dat je er naast zit, daar kan je dan wel weer overheen gaan met veel tekst en allerlei technische terminologie. Rechtpraten doe je het niet.
Je zat er gewoon naast met je reactie van 08:25 door karma4 en weet de argumenten van anderen niet overtuigend te weerleggen.
Geeft op zich niets.
Wat wel geeft is kritiek op een misvatting afdoen als bashen, dat is te makkelijk, zo kan je elke discussie wel doodslaan.

Nog een mixupje
Er is een verschil tussen gebruikmaken van de spellings- en grammatica controle en het aanzetten van de autocorrect functie.
De autocorrect functie kan inderdaad ongewild een tekst helemaal overhoop halen. Dat leek hier niet aan de hand, tenzij je een eigen correctielijst hebt aangelegd met verkeerd gespelde woorden.

De meeste mensen zetten dat UAC gewoon uit daar het in de veel gevallen een storende rol speelt tijdens het PC'en.

Schrijf 100 maal:

"Elke beveiligingsmaatregel waarbij de eindgebruiker moet oordelen is gedoemd te mislukken.
Het ontbreekt de eindgebruiker aan essentiële kennis om de gevolgen van de beslissing te kunnen overzien."

Kan zich iets in Explorer injecteren zonder dat ik daar dmv UAC al eerder toestemming voor heb gegeven? Ik dacht van niet; en het is dan niet heel veel anders dan een willekeurige installatieprogramma dat op moment van installatie willekeurig wat dan ook op mijn computer kan veranderen. De genoemde methode lijkt me dan ook uiterst omslachtig.

Wat ik mij afvraag of dit ook werkt als group policy " Computer Configuration-> Administrative Templates-> Windows Components-> Credential User Interface / Require trusted path for credential entry enabled wordt.
Hierdoor wordt er altijd een securedesktop opgestart. Vreemde is wel dat Microsoft deze instelling aanbeveelt. Nadeel is dat je een extra CRTL + ALT + DEL scherm krijgt.

Dit heeft alleen gevolgen voor de inlogprocedure.